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ABSTRACT 


The increasing demand for wireless services in both the military and civilian 
sectors results in the emergence of new communication standards and protocols to 
support these wireless services. There is a need for modern radio receivers to have the 
ability to receive and recover multiple wireless signals without the added complexity of 
additional hardware components. Fortunately, a single radio can accomplish these tasks 
by using software radio architectures where the radio has the ability to reconfigure itself 
based on the system it will be interfacing with and the functionalities it will be 
supporting. These radios are more commonly referred to as software defined radios 
(SDRs). This thesis focuses on using software radio techniques to design and implement 
software components for an IS-95B wireless transceiver. Furthermore, these software 
components were built to comply with regulations specified by the Software 
Communications Architecture (SCA). The open source core framework tool Open Source 
SCA Implementation::Embedded (OSSIE) was used to design and build the software 


components necessary to implement functions of an IS-95B transceiver. 
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EXECUTIVE SUMMARY 


Radio communications is one of the most important aspects of all U.S military 
operations, especially when joint forces are working together to perform a mission. In 
past conflicts, such as the Grenada operation and Desert Storm, land forces could not 
always communicate effectively with Naval or Air Force units when support was needed. 
Furthermore, space is often a limiting factor in choosing how many and what types of 
radios should be implemented on military platforms. For example, submarines, tanks, and 
airplanes all have little room to store large numbers of radio equipment for performing 
different operations. The solution to solving interoperability and hardware space issues of 
current military radios is the use of software defined radios (SDRs). SDRs are radios built 
with the ability to perform multiple radio functions with the use of a single piece of 
hardware. In addition, SDRs provide software control of various modulation techniques, 
wide-band or narrow band operation, communications security functions, and waveform 


requirements of current and evolving standards over a broad frequency range. 


The benefits of using SDRs are huge. Some of these benefits include the ability of 
easily upgrading current services by simply upgrading software, reduction in time to 
build and maintain radio systems, reduction in hardware requirements, and ability to 
detect and reject interference from other signals. The Joint Tactical Radio System (JTRS) 
is the Department of Defense’s initiative to develop a family of revolutionary SDRs that 
will provide the armed forces with voice, data and video communications, as well as 
interoperability across the joint battle space. These SDRs will provide both line of sight 
and beyond line of sight capabilities to the military in terms of communications, 


intelligence, and surveillance. 


The Software Communications Architecture (SCA) is a nonproprietary open 
systems architecture developed and maintained by the JTRS Joint Program Executive 
Office. The SCA is used in the development of SDRs by specifying the structure and 
operations within a SDR. The SCA is also being adopted for use by industry for 
commercial applications of SDRs. The Object Management Group (OMG) and the SDR 


Forum are working on creating an international commercial standard based on the SCA. 
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Furthermore, some research institutes are using the SCA as a standard for developing 
SDRs. The Mobile and Portable Radio Research Group at Virginia Tech University 
created the Open Source SCA Implementation::Embedded (OSSIE), an open source SDR 
development effort to enhance research and education in SDRs and _ wireless 
communications. OSSIE includes a SDR core framework (CF) based on the SCA. OSSIE 
enables radio designers to create radio applications using software components for 
implementing many of the functionalities normally performed by hardware components 
of a radio. OSSIE comes with a design tool, the OSSIE Waveform Developer (OWD). 
The OWD enables the creation of software components, and then allows radio 


waveforms to be developed and deployed as part of a radio system. 


The main objective of this thesis involves designing and implementing 
components belonging to the physical layers of a cellular Code Division Multiple Access 
wireless transceiver using the OSSIE version 0.5.0 architecture that complies with 
version 2.2.1 of the SCA standard. Specifically, we concentrated on the standard 
commonly known as IS-95B. This thesis only focuses on an IS-95B transceiver for 
downlink communications. While the ultimate goal of this research work is to develop a 
complete radio transceiver, including hardware, we only focused on developing software 
components that can perform modulation and demodulation of IS-95B signals. The 
software components were built to process baseband data only, assuming that all other 
functions, such as analog to digital and digital to analog conversion, filtering, and up- 


conversion and down-conversion, occur using hardware. 


One of the contributions of this work is flexible software components that can be 
reused and reconfigured for application in multiple radio designs. These components 


were added to an existing library of software components. 


To assist in the development of the transceiver, a systems engineering “VEE” 
process model was adopted. This model allows the transceiver system to be developed in 
a systematic and efficient manner. The model started with the development of system 


requirements. These requirements are stated below: 


e The system must be able to transmit and receive IS-95B signals. 
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e The system must have the capability to interface with hardware portion of 


a radio transceiver. 


e The system must be built with software components that meet the 


requirements of the SCA. 


e The system must be built with as little complexity as possible to allow for 


ease of testing, data processing, and reconfiguration. 


Once these requirements were determined, the second task was to assign a set of 
sub-systems for performing tasks that can meet the requirements previously stated. The 
sub-systems chosen were a transmitter for modulating and transmitting IS-95B signals 
and a receiver for receiving and demodulating IS-95B signals. When considering the 
design of the receiver, a decision was made to perform synchronous recovering of IS-95B 
signals only. To design the receiver to perform non-synchronous operations involves 
developing components to perform code acquisition and tracking, as well as carrier 
acquisition and tracking. In order to scope this research appropriately for a single 
master’s degree thesis, a decision was made not to pursue building these components due 


to time constraints. 


After sub-systems determination, the sub-systems were further broken down into 
a set of components, each assigned with a specific task. Each component is responsible 
for performing one or more tasks normally performed by an IS-95B physical layer 
hardware device. To determine the number of components needed, as well as the 
functionality of the components, block diagrams of the physical layers of a typical IS- 
95B forward link communications system were used. For the transmitter a total of eight 
components were chosen to perform the same functions of an IS-95B forward link 
transmitter. For the receiver, a total of 15 components were chosen to perform the same 


functions of an IS-95B forward link receiver. 


After determination of the types and quantities of components needed for our 
system, the next task involved building the components. The components were built with 
the ability for easily reusing or reconfiguring the component such that more features can 
be added or current features can be modified. This provides for one of the many 
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advantages of a SDR design. In addition, many of the components were built in tandem 
where a transmitter component was first built and tested, followed by a corresponding 
receiver component that could be tested by using the processed data output from the 


transmitter component. 


Once the components were developed, the next process involved detailed testing 
of the components to ensure functionality in accordance to the IS-95B standard. The 
testing stage involved an incremental approach. First, individual component testing was 
conducted, followed by integration testing using multiple components, and finally ending 
with complete transceiver testing involving all transmitter and receiver components. The 
final testing phase involved generating random binary data in the transmitter, modulating 
the data, sending the data to the receiver, demodulating the data, and verifying that the 
data in the receiver matched the random binary data generated by the transmitter. The 
testing stage was probably the most demanding and time consuming aspect of this project 
due to the number of components that had to be tested, but also due to the complexity of 
some of the components implemented by software. In the end, all test results were 


considered successful. 


After the testing stage, the next step was to verify the transceiver design by 
ensuring that the transmitter and receiver both performed in accordance with given 
specifications. In this stage both the transmitter and receiver met all of their given 
objectives in being able to successfully implement functions normally performed by 
specific IS-95B hardware components. Following the verification stage, the final stage 
involved validating the entire transceiver design by ensuring that the transceiver met all 
of its requirements. In this final stage, the transceiver design was checked against each 
requirement. The result from the validation stage was an IS-95B transceiver system that 


met all of the given requirements. 
The following is a summary of the results of the thesis work conducted. 


e A SDR transceiver design implemented for a forward link IS-95B wireless 


system using the SCA compliant architecture, OSSIE, version 0.5.0. The 


XX 


transceiver performs data processing for single mode operations 


corresponding to the IS-95B data rate of 14.4 kb/s. 


Transceiver design consists of two primary sub-systems: a transmitter and 
a receiver. Each subsystem developed with multiple components, eight 
components for the transmitter and 15 components for the receiver. The 
components perform one or more functions that typical IS-95B forward 


link hardware components perform. 


All components built with SDR features, to include ability for 
reconfiguration and reuse by other radio applications. The components are 
available as a growing library of software components in a repository at 
the Naval Postgraduate School. Each component is well documented to 
allow other designers to follow programming logic for implementing the 
functionality of the component. In addition, the components are designed 
to allow future radio designers to easily modify, add, or remove 


processing functions. 


The transceiver design provides a solid foundation for implementing a 
complete IS-95B SDR transceiver by providing the software components 
necessary for modulating and demodulating the baseband portion of IS- 


95B signals. 


Future design considerations include building software components to perform 


other features of an IS-95B forward link system to include code acquisition and tracking 


of an IS-95B signal, and carrier acquisition and tracking of an IS-95B signal. 
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I. INTRODUCTION 


A. BACKGROUND 

Beginning in early 2005, Assistant Professor Frank Kragh from the Naval 
Postgraduate School (NPS) collaborated with the Mobile and Portable Radio Research 
Group (MPRG) at Virginia Tech University to initiate research at NPS into the 
development of software defined radios (SDRs) using the software architecture, Open 
Source SCA Implementation Embedded (OSSIE), that was developed by the MPRG [1]. 
A Software Radio course was taught in the spring of 2006 at NPS and this course has 
facilitated a huge interest by communication students at NPS to conduct research into 
SDRs. This thesis is an attempt to develop and build a radio transceiver using software 
radio techniques, specifically an IS-95B! code division multiple access (CDMA) 
transceiver and in some ways this thesis is an attempt to show that software defined 


radios may indeed be the future of radio communications. 


Considering the model of a software radio taken from reference [2] and displayed 
in Figure 1, a software radio can be separated by its software and hardware components 
as indicated by the dashed blue rectangle. For this thesis, we will only consider the 
development of software components of the radio as indicated in blue. These software 
components will be capable of processing data using a general purpose processor found 
on a desktop computer or laptop. Developing a complete software radio system, including 
hardware, using the software components developed in this project will be considered for 
future theses and design projects. For all practical purposes, it can be assumed that all 
other components of a complete software radio can be built and implemented to transmit 


and recover IS-95B signals. 


For this thesis, the transmitter software components have the task of producing 
signals in the form of digital samples that replicate the signals produced by an IS-95B 
hardware-based physical layer interface. These digital samples would then be sent to the 
radio frequency (RF) hardware portion of the transmitter where such features as filtering 

! The IS in IS-95B is Interim Standard. The official name of the IS-95B wireless standard is 
Telecommunications Industry Association/Electronics Industry Alliance-95-B (TIA/EIA-95-B). IS-95B is 


the old name of the standard that is still commonly in use. The IS-95B standard is now known as CDMA 
one. 


and amplification would occur. Likewise for the receiver, the RF hardware portion of the 
radio is responsible for performing features such as filtering, amplification with a low 
noise amplifier, and mixing with a local oscillator to produce an intermediate frequency. 
This intermediate frequency is then sampled in the analog to digital conversion process, 
followed by digital filtering and sample rate conversion processes to produce the desired 
baseband digital output that would then be processed by the receiver software 
components. The channelization (digital filtering) and sample rate conversion processes 
are performed in software using digital signal processors (DSPs), field programmable 
gate arrays (FPGAs), or application specific integrated circuits (ASICs) [2]. For this 
thesis, only the baseband digital signals resulting from the channelization and sample rate 
conversion processes are required to effectively build and test the software radio 
transceiver design. Furthermore, channelization and sample rate conversion is possible 
using software components but are not needed for this project since the actual waveforms 


produced will not be tested over an open air interface using a complete radio transceiver. 
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Figure 1. | Software Defined Radio Model (After [2]). 


B. GOALS OF RESEARCH 
The major goal of this thesis is to use software radio techniques to build a 
communications transceiver that implements the physical layers of a traditional IS-95B 


base station transmitter and corresponding mobile receiver. Specifically, only the forward 


link channel of an IS-95B system will be considered for this project. The design consists 
of two independent parts. The first part is to design and build a base station transmitter to 
produce a baseband digital signal that resembles as closely as possible an IS-95B 
baseband digital signal. The second part consists of designing and building a mobile 


receiver to recover and decode the IS-95B baseband digital signal built by the transmitter. 


It is desired to build the transceiver using only software radio techniques. 
Furthermore, we seek to comply with the Software Communications Architecture, which 
is design guidance offered by the Joint Program Executive Office (JPEO) for the Joint 
Tactical Radio System (JTRS) that standardizes interfaces, defines middleware, and 
facilitates software reuse. As such, the OSSIE architecture is chosen as the software 


architecture to use based on its compliance with the SCA and its open source nature. 


C. RELATED WORK 

Two successful theses regarding SDRs have recently been completed at NPS. 
“Software Communications Architecture (SCA) Compliant Software Defined Radio 
Design for IEEE 802.16 WirelessMAN-OFDM Transceiver’ [3] by Kian Low and 
“Software Defined Radio Design for an IEEE 802.11a Transceiver using Open Source 
Software Communications Architecture (SCA) Implementation::Embedded (OSSIE)” [4] 
by Chris Leong. These two theses represent the first attempts to use OSSIE for designing 
SDR components for two commonly used wireless local area networks (WLAN) 
standards. The major contribution of both theses is a library of software components. 
These software components can be used as a foundation for implementing complete SDR 
transceivers for the afore-mentioned [EEE 802.16 and IEEE 802.11a transceivers. In 
addition, the software components are flexible such that they can be reused or 


reconfigured for other SDR applications. 


The MPRG has been successful in developing both an AM and an FM SDR 
receiver using OSSIE. The MPRG used the Universal Software Radio Peripheral as a 
hardware source for the AM and FM receivers. The USRP is a low cost hardware device 
designed for implementing software radios. The USRP can connect to a personal 
computer through a universal serial bus (USB) connector. The USRP consists of four 


high-speed analog to digital converters, four high-speed digital to analog converters, a 
5} 


FPGA, and a programmable USB 2.0 controller [1]. The MPRG have used the USRP 
with OSSIE to perform reception over the air of AM and FM signals. The MPRG is also 
currently testing the USRP as part of a SDR transceiver for voice communications over 


an industrial, scientific, and medical (ISM) radio band. 


D. THESIS OUTLINE 
This thesis has been divided into eight chapters. The following shows the details 


of each chapter: 


Chapter I: Introduction. This chapter provides an introduction to the thesis, to 
include background information and the specific goal of the thesis. The chapter also 


includes related work. The chapter concludes with the thesis outline. 


Chapter II: Overview of SDR. This chapter is an overview of software defined 
radios and includes some important SDR concepts, such as the SCA and OSSIE. This 
chapter also indicates some of the benefits and disadvantages relating to SDRs as well as 


some of the current and developing applications of SDRs. 


Chapter III: Background of IS-95B standard. This chapter provides an overview 
of the IS-95B standard. In this chapter we focus on giving a brief description of the IS- 
95B standard, focusing mainly on the IS-95B forward link since this is what is actually 
being implemented in this thesis. Descriptions of the specific transceiver components that 


will be implemented by the SDR transceiver are given. 


Chapter IV: Design Methodology. This chapter outlines the design approach for 
this thesis. Specifically, the systems engineering process model used throughout this 
research thesis project is described. In addition, a description of the software components 


used to design the transceiver is introduced in this chapter. 


Chapter V: Transmitter Design and Development. The complete design and 
development of the IS-95B SDR transmitter is found in this chapter. Here, the software 


components used to build the transmitter are described. 


Chapter VI: Receiver Design and Development. The complete design and 
development of the IS-95B SDR receiver is found in this chapter. Here, the software 


components used to build the receiver are described. 


Chapter VII: Testing, Results, System Verification, and System Validation. This 
chapter shows the testing methods used to test the IS-95B SDR transceiver along with the 


results. The chapter also explains how the transceiver design is verified and validated. 


Chapter VIII: Conclusions and Future Considerations. This chapter details the 
conclusions from all the research conducted with this thesis. The end of the chapter 
outlines some considerations and recommendations for future research with SDRs for this 


design as well as other SDRs. 
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H. OVERVIEW OF SOFTWARE DEFINED RADIO 


A. WHAT IS A SOFTWARE DEFINED RADIO 

According to Jeff Reed, a software defined radio “is a radio that is substantially 
defined in software and whose physical layer behavior can be significantly altered 
through changes to its software” [2]. A software defined radio performs modulation and 
demodulation of signals using software, and is usually built with static hardware 
components that use software to change the functionality of the radio via reconfiguring 


the hardware [5]. 


B. HISTORY OF SDR 

The U.S military can be credited with the history of the first software radios in a 
military project called SpeakEasy. This SpeakEasy system was designed to enable the 
Army to operate a multifunctional radio capable of communicating with ground force 
radios, Air Force radios, Naval radios, and satellites. The SpeakEasy project is the first 
known system to use field programmable gate arrays (FPGAs) for signal processing of 
radio signals [6]. The SpeakEasy project became increasingly popular and the U.S 
government realized the importance of such a project and they formed the Modular 
Multifunction Information Transfer System (MMITS) to proliferate the emergence and 
acceptance of SDRs. The MMITS later became known as the SDR Forum [7]. Following 
the SpeakEasy project, the Department of Defense (DoD) realized that they faced some 
operational and logistical challenges concerning SDRs. The DoD was concerned about 
the need to support advanced services and the need to simplify procurement and 
maintenance [8]. They decided to create the Joint Tactical Radio System (JTRS). JTRS is 
a DoD wide initiative designed to create a family of revolutionary SDRs that will provide 
the military with voice, data and video communications, and inter-communication 
capabilities between different military forces. One of the major milestones created by 
JTRS is the Software Communications Architecture (SCA). The SCA is a nonproprietary 
open architecture developed to specify the structure, organization, and operation of SDRs 
used by the military [9]. A more detailed explanation of the SCA is found later in this 
chapter. 


1. Current Military Applications 


The JTRS Joint Program Executive Office is actively managed by three distinct 


domain program management offices and one special radio systems management office. 


These management offices facilitate the development of SDRs that will be built on 


requirements set forth by the various branches of the military. Table | outlines the focus 


of the JTRS program offices. [10] 





Ground Domain 


Airborne, Maritime 


and Fixed Domain 


Support requirements for Army and Marine Corps ground 


vehicular platforms 


Support requirements for JTRS handheld and manpack 
units and forms suitable for integration into platforms 


requiring a Small Form fit radio 


Support requirements for airborne (including rotary wing), 


maritime, and fixed wing station platforms for all services 


. Migrate the current multifunctional information 


distribution system (MIDS)-low volume terminal to 
MIDS-JTRS compliance producing the next generation 
data link and communication terminal for joint and 


coalition tactical platforms 





Network Enterprise 


Responsible for waveform development, cryptographic equipment 











Domain applications, architectural integrity of JTRS, gateways and 
common network services 

Special radio | Support requirements for handheld radios for the Army, Navy, 

Systems Marine Corps and Air Force Special Operations Forces 





Table 1. 


JTRS programs (After [10]). 





C. ADVANTAGES AND DISADVANTAGES OF SDR 


1. 


SDR Advantages 


A software radio is built around flexible hardware and software architectures. 


This flexibility in radio design allows a software radio to change its personality rather 


easily. For example, the flexibility in the radio architecture allows service providers the 


ability to upgrade infrastructure and market new services quickly. Furthermore, the 


combination of both flexible hardware architecture and flexible software architecture 


provides a software radio with the ability to easily integrate itself into multiple networks 


with different air and data interfaces. In addition, software radio architecture enables a 


system to add new capabilities through the use of software. Some of these capabilities are 


interference rejection, encryption, software-enabled power minimization and control, and 


advanced error correcting schemes [2]. There are many other advantages that SDRs offer. 


Some of these advantages are listed below. 


A SDR has the ability to transmit and receive various modulation methods 
using the same hardware. For instance, a software radio can be installed in 
a laptop to perform both wireless networking using, for example, the IEEE 
802.1la standard, while at other times acting as a fax receiver using a 


Bluetooth interface [5]. 


A SDR has the ability to alter functionality by downloading and running 


new software as needed [5]. 


Using a SDR results in a more compact and power efficient design since 
the same piece of hardware is reused to implement multiple systems and 


interfaces [2]. 


When using a SDR, it is possible to adaptively choose an operating 


frequency and a mode best suited for prevailing conditions [5]. 


RF components have been known to be hard to standardize and have been 
known to sometimes vary in performance. It may take several years to 


achieve optimum performance, resulting in production delays. By using a 


software radio approach and digitizing the signal as early as possible in the 
receiver chain, radio designs can be built with fewer parts and fewer 


delays [2]. 


e Using SDRs provides the opportunity to recognize and avoid interference 


with other communications channels [5]. 


The future for SDRs looks bright, especially for military applications. The 
commercial world is also looking at possible uses of SDRs for the future, to include use 
in next generation satellite systems and implementation of 4G wireless services [5]. 

2. SDR Disadvantages 

While SDRs offer many benefits as outlined previously, Banerjee and Ganapatti 


recognize that SDRs do have some disadvantages as outlined below [5]. 
e Itis difficult to write software for various target systems. 
e There is a need for interfaces to digital signals and algorithms. 
e Some SDR designs incorporate poor dynamic range. 


e There is often a lack of understanding among designers as to what is 


required when building and designing SDRs. 
e Complex Networking protocols are required 
e Huge efforts in standardization and regulation are required 
e Using SDRs results in huge security implications. 


As with most new technological advances, research and development will more 


than likely pave the way in finding ways to resolve the disadvantages listed above. 


D. SCA 

1. Introduction 

As mentioned previously in this chapter, the JTRS was developed to alleviate 
many of the problems and issues concerning radios in the military. At the backbone of all 
SDRs is an architecture that specifies the operations within a SDR. The JTRS Program 


developed the SCA to use for the development of military radio systems [11]. 
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The SCA is an open architecture framework that describes how hardware and 
software are to operate together as part of a SDR [11]. It is the rule book for designing 
SDRs developed under JTRS. The SCA is now also becoming a popular architecture for 
commercial applications of SDRs. The Object Management Group (OMG) and the SDR 
Forum are working on creating an international commercial standard based on the SCA 
[5]. The main purpose of the SCA is to provide a framework to allow the interoperability 
of components. This includes building flexible software components that are easily 
reconfigurable and reusable [5]. 

2. SCA Functions 

Since a SDR is reconfigurable and mostly defined by software, it must be able to 


accomplish the following general tasks as referenced from [11]: 


e A method to keep track of the whole radio system to include general 


system attributes, file structure, and naming structure 


e Use hardware controllers to control multiple hardware platforms that are 


used for running various radio applications 


e A method to establish which application (i.e. GSM, 802.11, IS-95B) to run 


on a specific platform, and 
e A method to launch an application 


The SCA was developed with the above general tasks in mind. The software 
structure of the SCA consists of the following components: an operating system (OS), 
Common Object Request Broker Architecture (CORBA) middleware, and the SCA Core 
Framework (CF). The overall SCA system structure is illustrated in Figure 2 taken from 
reference [11]. The CF is split into a secure and non secure section denoted by red and 
black. The SCA does not specify how to separate the two sections, but this could be done 
with some specialized OS or through some other mechanism. These details are left to the 


system developers [11]. 
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Figure 2. Overview of SCA system structure (From [11)). 


a. OSs 

The SCA requires a POSIX- compliant operating system that is based on 
the real-time controller system profile (PSE52) defined in POSIX 1003.13. Using a 
POSIX-compliant operating system enables a set of system calls with defined semantics 
and the ability to support multi-threaded operations, enabling multiple, simultaneous 
operations to be carried out at the same time. [12] 

b. CORBA 

Central to the SCA is CORBA. CORBA is used to allow communication 
between software components written in multiple computer languages and operated on 
different platforms [12]. In the case of the SCA, CORBA allows two objects to be 
connected through a virtual channel. For example, on object running on a DSP may be 
trying to communicate with an object running on an FPGA. CORBA uses an interface 
description language (IDL) to represent the interface between different objects that are 


using CORBA to communicate. IDL is used to generate the interfaces necessary for an 
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object to communicate with another object. When two objects are trying to communicate, 
CORBA uses IDL to produce an API (Application Programming Interface) that is used to 
standardize the semantics of the interface. The combined use of an API and IDL 
guarantees that the semantics are compatible, through the API, and that the data is 
transferred correctly, through IDL [11]. 

c. SCA Core Framework (CF) 

Each SDR has a specific function or task and the SCA’s Core Framework 
is a way of describing a set of relationships that are used to organize the functionality of 
the different objects (or components) that are part of a SDR. The CF is basically a set of 
cooperating classes that are readily available and reusable, allowing multiple radio 
designs to occur. The CF uses a set of open interfaces and services that allow radio 
designers with a uniform way of managing components and waveforms. Components 
associated with a SDR communicate with each other via its associated interfaces and by 
using CORBA. The following interfaces belong to the SCA CF: Base Application 
Interfaces, Framework Services Interfaces, Framework Control Interfaces, and Domain 
Profile [11]. For more specific information on the SCA CF, please refer to reference [11]. 


Figure 3 further illustrates the structure of the SCA CF [11]. 
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Figure 3. © SCA CF (From [11]). 


3. XML Profiles 

The SCA specifies that components and devices that are part of a waveform or 
particular domain are to be described by XML descriptor files [12]. XML (Extensible 
Markup Language) is a programming language used to facilitate the sharing of data 
across different information systems [8]. 

4. Additional Information on SCA 

The SCA is well documented and updated by JTRS on a regular basis. For a more 
thorough explanation of the SCA, refer to references [11] and [13]. 


E. OPEN SOURCE SCA IMPLEMENTATION::EMBEDDED (OSSIE) 

OSSIE is an initiative started by the Mobile Portable and Radio Research Group 
(MPRG) at Virginia Tech University to provide an open source, C++ based SCA 
compliant architecture that could be used for research and development of SDRs [1]. The 
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major goals set about for creating OSSIE are to create a design environment with a quick 
learning curve, to create a design environment capable of supporting multiple radio 
interfaces (AM, FM, GSM, 802.11, etc), and to provide an interface for sharing SDR 
research and development among different institutions [8]. OSSIE is written in C++ for 
Linux based operating systems and uses open source supporting software to include 
CORBA and Xerces. The first version was released in the summer of 2004 and the latest 
version (0.6.0) was recently released in the fall of 2006. This thesis uses OSSIE 0.5.0 for 
the development of the IS-95B transceiver. 

1 Bs OSSIE Waveform Developer (OWD) 

OSSIE was created with simplicity in mind. The MPRG realized that a user 
friendly design tool was needed that would allow radio designers and students the ability 
to easily develop radio waveforms without having to worry about the intricate details of 
the SCA CF environment. “A waveform is the entire set of radio and/or communications 
functions that occur from the user input to the radio frequency output and vice versa,” 
[10]. OSSTIE Waveform Developer (OWD) was created to perform these tasks. OWD is a 
software tool containing a graphical user interface built around the python language. 
OWD allows users to create software components and to use these components to build 
waveforms. The OWD environment generates SCA Domain Profiles, OSSIE-specific 
XML, skeleton C++ code, and Autoconf configuration files for installation. [12] 

a. Installation Structure 
OWD is designed with the following installation file structure taken from 


reference [12]. 
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Figure 4. | OWD file installation structure (From [12]). 


This file structure is compliant with SCA specifications and provides a 
uniform way of installing and managing components and waveforms by specifying 
exactly where the files associated with components and waveforms are to be installed. 
Furthermore, this file structure facilitates the creation of a component library where 
components can be stored and readily available for use by multiple SDR applications. 
[12] 

b. Component Design 

The OWD is used to create generic SCA compliant components. These 
components are all uniform in nature and allow the actual function of the component to 
be programmed by the radio designer without the designer having to worry about the 
inherent structure of the OSSIE CF. When a component is created in OWD, C++ code 
and XML files are created that are necessary to install the components and waveforms as 
well as run the application waveform. To facilitate creating these uniform components, a 
port communications structure was developed. This port structure is based off of C++ 
classes. A C++ class is an expanded concept of a data structure that can hold both data 


and functions. [12] 
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(1) Port Implementation Strategy: A Uses and Provides class is 
created to allow components to easily communicate with each other through a designated 
port or multiple ports. A uses port allows information to flow outward from one 
component to the next and a provides port allows information to flow inward from a 
component [12]. Use of two distinct types of ports allows compatible communication 
between two components where a component with a specific uses port can only 
communicate with another component with a compatible provides port and vice versa. 
DePriest states that “Each port inherits from a specific [DL-defined interface that defines 
the type and method of communication that it can support,” [12]. These interfaces are 
C++ data types and examples of these interfaces include realShort, realFloat, 
complexShort, and complexFloat. This port implementation scheme makes it clear what 
interfaces are being used to handle given communications [12]. Figure 5 from reference 


[12] illustrates some of the possible communication schemes between two components. 


m—— 
L_] Component 1 J-——>_] Component2 I C] Component 4 Component 2 [ij 
a 
Component 2 [i [_] Component 1 
[_] Component 1 -[_] Component3 J 
Component 3 [] Component 2 
[Mm Uses | 
| H 
eee | 


Figure 5. | Possible component layouts (From [12]). 
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(2) Assembly controller: The assembly controller is a special 
component used to specify the starting and ending point of the waveform. The assembly 
controller is a resource that calls a start method that allows the waveform process to 
begin and also calls a stop method that ends the waveform process. The assembly 
controller is specified using OWD. [12] 

ce File and Directory Structure 

Figure 6 from reference [12] describes the file and directory structure 
created by the OWD when generating a waveform. Each component’s files are stored in a 
separate directory, except for the assembly controller component, which is associated 
with the waveform directory. Each component generates the necessary XML, C++, and 


auto-configuration files necessary for building and installing waveforms [12]. 





Assembly | [_ ovprentXMe 
Controller || Comper 
Auloconf Files 
—_ | Waveform aetna 
Name Pastfoem XML 
Autocar’ Files 
Com Component XML 
—— a9 vent Component H+ 
Auloconf Files: 
Output 
Directory 
Component XML 
—— sats pla Component C++ 
Autoconf Files 


Figure 6. © OWD file and directory structure (From [12]). 


18 


The files auto-generated by OWD for each component are listed in Table 


2. For a description of these files, please refer to reference [12]. 
















































































File Type 
DomainManager.dmd.xml SCA Waveform XML 
DomainManager.spd.xml SCA Waveform XML 
DomainManager.scd.xml SCA Waveform XML 
DomainManager.prf.xml SCA Waveform XML 
DeviceManager.dcd.xml SCA Waveform XML 
DeviceManager.spd.xml SCA Waveform XML 
DeviceManager.scd.xml SCA Waveform XML 
DeviceManager.prf.xml SCA Waveform XML 
<Waveform Name>.sad.xml SCA Waveform XML 
<Waveform Name>.DAS.xml SCA Waveform XML 
Configure.ac autoconf file 
Makefile.am autoconf file 

Reconf autoconf file 

Aclocal.d autoconf directory 
<Component Name>.spd.xml SCA component XML 
<Component Name>.scd.xml SCA component XML 
<Component Name>.prf.xml SCA component XML 
<Component Name>.h OSSIE component C++ 
<Component Name>.cpp OSSIE component C++ 
main.cpp OSSIE component C++ 
port_impl.h OSSIE port implementation C++ 
port_impl.cpp OSSIE port implementation C++ 
Configure.ac autoconf file 
Makefile.am autoconf file 

Reconf autoconf file 

aclocal.d autoconf directory 








Table 2. OWD auto-generated files (After [12]). 


These files are generated when using OWD for OSSIE version 0.5.0 only. 
What makes OWD such a wonderful software tool is that the radio designer only has to 
add C++ code to the following four C++ files to implement the SDR component’s 
specific functionality: <Component Name>.h, <Component Name>.cpp, port_impl.h, and 
port_impl.cpp [12]. <Component Name>.h is a header file associated with each 
component that describes all of the class definitions associated with each component. 
<Component Name>.cpp is used to implement the methods which describe the main 
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functionality of the component. Methods for processing data are included in this 
component. Port_impl.h is a header file that contains C++ class definitions for each type 
of port interface associated with a component. The port_impl.cpp file contains the 
implementation of the methods declared in the port_impl.h file to include methods for 
receiving and transmitting data in and out of a component [12]. The latest version of 
OSSIE, 0.6.0, has been modified where the port_impl.h and port_impl.cpp files no longer 
exist and the radio designer only has to modify two C++ files, <Component Name>.h and 
<Component Name>.cpp. For a more detailed explanation of OSSIE and OWD, refer to 


reference [1] or reference [12]. 


The OWD was used to develop the components needed to build the IS- 
95B transceiver. Once the generic software components were created, the four C++ files 
associated with each component were modified with C++ code tailored to meet the 
specific function of that component. Chapter IV describes the general description of each 


component used in the IS-95B transceiver. 


F. SUMMARY 

This chapter presented a general overview of the fundamentals behind a SDR. 
The chapter also briefly described OSSIE and its software tool, the OWD. All of the 
intricate details regarding the SCA and OSSIE are beyond the scope of this thesis, but 
there are many outside references available if the reader is interested in pursuing these 
topics further. Some of these references include references [1], [8], [11], [12], and [13]. 
The next chapter provides the reader with a general overview of the IS-95B 


communications system that will be implemented in this thesis using a SDR approach. 
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HiIl. BACKGROUND ON IS-95B STANDARD 


A. INTRODUCTION 

The Interim Standard 95 (IS-95) air interface standard is based on Code Division 
Multiple Access (CDMA) technology that first appeared in the wireless commercial 
industry in the early 1990’s. CDMA is a method of transmitting multiple, independent 
signals across the same frequency band by spreading the information signals with a set of 
orthogonal codes at a much higher frequency baud rate, and then frequency up- 
converting. At the receiver end, the received signal is first down-converted to a baseband 
signal. The mobile receiver produces the same unique code used in the transmitter and 
recovers the information data by performing a correlation operation between the received 
baseband signal and the unique code. CDMA is a form of Direct Sequence Spread 
Spectrum communications. Direct Sequence refers to the spreading of the information at 
the transmit frequency and Spread Spectrum refers to spreading low data rate information 


with a code at a higher baud rate. [14] [15] 


IS-95A is one of the first air interface standards used to describe a CDMA cellular 
system. It describes cellular systems at the 800 MHz frequency band. A CDMA air 
interface called ANSI J-STD-008 specifies the air interface for Personal Communication 
Services (PCS) at 1900 MHz. TSB74 is another air interface standard that describes IS- 
95A and CDMA PCS systems at a maximum data rate of 14.4 kilobits per second (kb/s) 
compared to a maximum data rate of 9.6 kb/s for IS-95A and PCS. IS-95B, also called 
TIA/EIA-95, merges IS-95A, ANSI J-STD-008, and TSB 74 standards into one 
document. In addition, IS-95B offers much higher data rates by having the ability to 
bundle up to eight 14.4 kb/s channels together for a maximum data rate of 115.2 kb/s. 
This increased data rate allows transmission of email, web browsing, mobile commerce, 
and location based mobile services in addition to voice communication. There is not very 
much difference between IS-95B and IS-95A at the physical layer except for the higher 
data rates achievable by IS-95B and the ability of IS-95B to provide both high-speed 
packet and circuit switched data access on a common CDMA channel. IS-95B can 
operate in two main modes, at rate set one (9.6 kb/s maximum data rate per traffic 


channel) and rate set two (14.4 kb/s maximum data rate per traffic channel). IS-95B 
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functions essentially in the same way as IS-95A with regards to modulation and 
demodulation schemes. Furthermore, In IS-95B, the higher layers, such as the multiple 
access layer (MAC) and network layers are designed for improved performance to 


account for the changes and benefits IS-95B offers over IS-95A. [16] [17] 


When consulting wireless cellular standards, it is important to note that these 
standards provide engineers with an overview of the characteristics and limitations to be 
imposed on the signaling protocols and data structures, but do not specify exactly how a 
cellular system must be implemented. With this in mind, the rest of this chapter will 
focus mainly on the development and characteristics of a typical IS-95 cellular system 
based on reviews of the IS-95A and IS-95B standards obtained from various references. 
Specific attention to a circuit switched based IS-95B system will be adhered to for 
attainment of a maximum data rate of 14.4 kb/s per channel. All other features of an IS- 
95B system can be assumed to resemble those of an IS-95A system. It is also assumed 


that the reader has a basic understanding of cellular systems. 


B. IS-95B CELLULAR AIR INTERFACE (CAD) 

The IS-95B system interfaces with the Public Switched Telephone System 
through a Mobile Telephone Switching Office (MTSO) [18]. The MTSO connects to a 
set of base stations. These base stations communicate with the mobile receivers using two 
distinct communication links, the “forward” link for base station transmitter to mobile 
receiver communication and the “reverse link” for mobile transmitter to base station 
receiver communications [18]. The communication over these two links is organized into 
channels. The forward link consists of pilot, synchronization, paging, and _ traffic 
channels, while the reverse link consists of access and traffic channels. The two links 
have different modulation and multiple access techniques, but both conform to strict 
frequency and timing requirements [17]. The bandwidth of each IS-95B cellular channel 
is 1.25 MHz, supporting up to 64 users at any time [18]. The rest of this chapter will only 
focus on the forward link since this thesis concentrates on designing and building a 
transceiver that replicates the IS-95B forward link. For more information on the reverse 


link, please refer to references [14], [15], [16], [17] and [18]. 
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C; FORWARD LINK 

The forward link (also known as downlink) for an IS-95B cellular system consists 
of one pilot channel, one synchronization channel, up to seven paging channels, and up to 
55 traffic channels in each forward cell. The pilot channel is a high power pilot signal 
that is continuously transmitted and used by mobile receivers to perform coherent 
demodulation, acquisition of unique code phase used by base station for modulation of 
data, time delay tracking, and power control measurements. The synchronization channel 
is continuously transmitted and used to pass on system information to all mobile 
receivers in a cell. The paging channels are used to page a mobile receiver of incoming 
calls and channel assignments. The traffic channels transmit voice and data to the mobile 


receivers. More details on these channels will be given later in this chapter. [16] [18] 


The operation of the forward link IS-95B system is fairly straight forward. First, a 
communications channel is established between the closest base station and 
corresponding mobile receivers via acquisition of the pilot channel. Once the pilot 
channel is acquired, the synchronization (sync) channel is demodulated. Successful 
demodulation of the sync channel allows the paging channel and corresponding traffic 
channel or channels to be demodulated. [18] 

1. Forward Link Channel Structure 

a. Forward Link Channel Structure of IS-95B at Rate Set One 
Figure 7 shows a figure of the forward link channel structure for a typical 


IS-95B system at rate set one taken from [16]. 
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Figure 7. IS-95B forward link channel structure at rate set one (From [16]). 


b. Forward Link Traffic Channel Structure of IS-95B at Rate Set 
Two 


Figure 8 shows a diagram of an IS-95B traffic channel structure to achieve 
rate set two. At the bottom of the diagram is an illustration of the quadrature spreading 


and modulation technique used in IS-95B [16]. 
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Figure 8. IS-95B traffic channel structure at rate set two (From [16]). 
Zs Overview of IS-95B Forward Link Channels 


The following sections explain the modulation of the forward link channels up to 


point A in Figure 8. 
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a. Pilot Channel 

The pilot channel consists of all binary zeros (pilot symbols) and the pilot 
channel contains no information data. The pilot symbols are first modulated by the Walsh 
function HO, the 0" row of the 64 X 64 Hadamard matrix, at the chip rate of 1.2288 
million chips per second (Mc/s) where a chip refers to a bit value from the Hadamard 
matrix. The Hadamard matrix is a square array of plus and minus ones, with rows and 
columns that are mutually orthogonal. The 64 X 64 Hadamard matrix is illustrated in 
Appendix A. Because the pilot channel contains no data modulation and is transmitted by 
a higher power level than all the other channels, it is easily acquired by the mobile 
receivers. [18] 

b. Synchronization Channel 

The sync channel relays important system information, such as the identity 
of the base station by specifying the base station’s pseudo-noise (PN) code offset. Each 
base station generates in phase and quadrature PN sequences as shown in Figure 8. The 
period of the sequences is 32768 chips where a chip corresponds to one bit value of the 
sequence. A total of 512 possible, unique offsets of the sequences may be created by 
dividing the period of 32768 chips by 64. Each base station generates one of the 512 
possible PN sequences. The in phase and quadrature PN code sequence generators are 
further explained later in this chapter under Heading F. Each base station transmitter also 
uses a 42-stage PN code generator to produce a sequence for scrambling data. This 
generator has a very long period of 2” —1 chips long. To facilitate descrambling data at 
the mobile receiver, the sync channel provides the mobile receiver with the current 42-bit 
state of the generator so that the mobile receiver can start creating the correct PN 
sequence values for descrambling paging and traffic channel data. The sync channel has a 


data rate of 1.2 kb/s, or 32 sync channel data bits per sync channel frame. The sync 
channel data is convolutionally encoded by a rate : encoder, and then repeated to 


produce 4.8 kilosymbols per second (ks/s). Symbols in the IS-95B context refer to all 
data bits that have been encoded, repeated, interleaved, or scrambled. Unlike most 
convolutional encoders, the state of the convolutional encoders for the sync channel is not 


reset after each frame and hence no encoder tail bits are needed. Following encoding, the 


26 


sync channel symbols are interleaved one frame at a time in blocks of 128 symbols each. 
The interleaved symbols are then modulated by the Walsh function H32, the 32" row of 
the Hadamard matrix at a rate of 1.2288 Mc/s. [18] 

c. Paging Channel 

The paging channels have a data rate of 9.6 kb/s each. Each paging 
channel frame is 192 bits long and 20 ms in length. The paging channel data is 


convolutionally encoded with the same rate ; encoder used for the sync channel. In 


addition, the state of the encoder is not reset after each frame and hence no tail bits are 
needed. After encoding, the paging channel symbols are interleaved, one frame at a time, 
in blocks of 384 symbols each. Following interleaving, the symbols are scrambled using 
a 42-stage long PN code sequence generated at 1.2288 million chips per second (Mc/s) 
but decimated by a factor of 64 to produce a code rate of 19.2 ks/s thereby keeping the 
data rate the same. This PN code sequence is referred to as a long PN sequence due to the 
period of the sequence lasting over 41 days. The 42-stage long PN code sequence 
generator is illustrated later in this chapter under Heading F. The scrambled paging 
channel data is then modulated by one of seven Walsh functions, H1 to H7. [18] 

d. Traffic Channels 

For the maximum data rate of 14.4 kb/s, each traffic channel frames 
consists of 263 information bits, one flag bit, a 16 bit frame quality encoder(CRC), and 
eight tail bits used in the convolutional encoding process. The 16 bit CRC is used as a 
frame checking tool at the mobile receiver to check if the traffic channel frames contain 
bit errors. The CRC process is discussed further later in this chapter under Heading F. 
The effective data rate is 14.4 kb/s and each frame is 288 bits long and 20 ms in length. 


: ; : ; 1 
The traffic channel data is convolutionally encoded using a rate 5 encoder but the 
output, encoded data is punctured by removing two out of every six bits to produce an 
. 3 : : ; os 
effective code rate of rh Following encoding, the traffic channel data is interleaved, one 


frame at a time in blocks of 384 symbols each. The interleaved symbols are then 
scrambled using the same 42-stage long PN sequence used by paging channels. The 


scrambled data is then overwritten by power control bits at a rate of 800 bits per second 
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(b/s). Two consecutive bits are overwritten by the same power control bit. The insertion 
of power control bits follows a random pattern determined by the values of the last four 
long-code chips used for scrambling data in each 1.25 ms interval corresponding to 24 
chips. The 24" PN code chip is the most significant bit, followed by bits 23, 22, and 21. 
For example, if the last four scrambling long-code sequence chips 24,23,22,21 are 
1011=11, then the power control bits are inserted in positions 11 and 12 of the next 24 bit 
interval of the traffic channel data stream. These power control bits are used by the 
mobile receiver to control received power. The traffic channel data is then modulated by 
one of 55 possible Walsh functions. [16] [18] 

e. Quadrature Spreading for the Forward Link 

After the channel data reaches point A in Figure 8, the data is spread with 
two different “short” PN codes, each with a period of 32768 chips. These codes are not 
short because of the length of the sequence but the term short is used to distinguish these 
codes from the longer PN code used for scrambling data. The same channel data is spread 
by each of the short PN codes. The advantage of using this QPSK scheme compared to 
assigning alternate data values to the in phase and quadrature components comes from 
the analysis of instantaneous multiple access interference. By using this scheme, 
fluctuations in instantaneous multiple access interference do not occur when the different 
carrier phases from other users shift relative to that of the desired user. After the channel 
data is quadrature spread by the two short PN codes, the data passes through a finite 
impulse response filter used to control the shape of the emitted spectrum. The channel 
data is then finally modulated by in-phase and quadrature carriers, combined, and 
transmitted. The above modulation technique is often termed “quadrature spreading.” 


[18] 


D. IS-95B RECEIVER 

1. Demodulation of IS-95B Forward Link Signal 

An IS-95B receiver on the forward link uses coherent demodulation techniques. 
Before explaining how the receiver works, an analytical description of the IS-95B signal 


out of the transmitter is taken from reference [18] and shown in equation (1). 
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The transmitted forward link waveform can be written as 
s(t) = I(t)cos2zf ot + QO(t)sin 27 f o(t) (1) 
Where fo is the selected carrier frequency, and /(t)) and Q(t) are the in-phase 


and quadrature portions of the waveforms and 
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Lea) {Ci(t)[AnWa(t) Da(t) ]} (2) 
and 
Olt) = DY) {Colt)[AnWa(t)Du(s)]} (3) 


Ci(t) and Co(t)represent the two short + 1 PN sequences used for spreading the 


information data and clocked at 1.2288 Mc/s. An represents the digitally controlled 


transmitter amplitudes for each channel. W,(t) represents 64-chip + 1 periodic Walsh 
functions clocked at 1.2288 Mc/s and the D,(t) represent + 1 data symbols that have 


been coded, interleaved, and scrambled at a maximum rate of 19.2 ks/s. [18] 


Figure 9 illustrates an optimal demodulator for the nth forward link channel [18]. 


V2 cos @o(t) C(t) 


Tw 
r() detector D (t) 





2 sin @o(t) Colt) 


Figure 9. | Optimal demodulator for the nth link channel [After [18]]. 
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To demodulate an IS-95B communications signal, the receiver must generate and 
know the phase of the same spreading codes used to modulate the channel data in the 


transmitter. The received signal, r(t), is first down converted and filtered. The baseband 
data is then multiplied by the same two short PN codes, (Ci(t) and Co(t)), used in 
transmission, resulting in effectively removing the effects of quadrature spreading 
performed in the transmitter. The two resulting signals, r-(t) and7.(t), are then added to 
produce a single signal. This new signal contains up to 64 different orthogonally 


modulated channels sent by the transmitter. To extract each possible channel, a 


correlation operation is performed with each corresponding Walsh function (W,(t) ), to 


produce a set of decision statistics, Zn. The desired channel symbols, D, (t), may then be 


determined by a simple threshold detector or by using a quantizer [17]. A quantizer is a 
more suitable choice for better performance, especially when using a Viterbi decoder for 
decoding channel symbols. Quantization of incoming channel data offers about a 2.3 dB 
increase in coding gain over hard decision decoding [18] where the coding gain is defined 
the amount of additional signal energy per bit required for transmission in an uncoded 


system compared to a coded system and the equation for coding gain is: 


b 








Ge= [= Juncoded (dB) — | Z coded (dB) 
N N 


2) 





E» = energy per bit 


No = noise power spectral density 


The decision symbols out of the correlator for each possible type of channel 
(sync, paging, traffic) are then further demodulated by basically going through the 
reverse process of the forward link transmitter channel structure as summarized below. 


[17] [18] 


For pilot channels no demodulation occurs. This channel is mainly used for PN 


code acquisition and timing references [18]. 


For the sync channel, the channel data is deinterleaved, followed by symbol 
removal to reduce the data rate. Next, a Viterbi decoder is used to recover the original 


information data. A definition of the Viterbi decoder is given later in this chapter. 
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For the paging channel, the channel data is deinterleaved, and then descrambled 
by multiplying the channel data with the same exact 42-stage PN code used for 
scrambling. The descrambled data then passes through a Viterbi decoder and 


the original information data is recovered. 


For the traffic channel, the channel data is deinterleaved, and then descrambled by 
multiplying the channel data with the same exact 42-stage PN code used for scrambling. 
The descrambled data then passes through a Viterbi decoder and the original information 
data is recovered. The traffic channel data is then checked by a syndrome detector for 


frame errors. A definition of the syndrome detector is given in the next section. 


E. IMPORTANT IS-95B PHYSICAL LAYER COMPONENT 
DESCRIPTIONS 


The physical layers of a forward link IS-95B communications system consists of 
many similar components used for modulation and demodulation of information data. 
The receiver also consists of some unique components needed for demodulation 
purposes. The rest of this section is dedicated to describing some of the important 
components and principles used in an IS-95B base station and mobile receiver. This 
section also serves as an overview of the physical layer components that will be 
implemented in this thesis using SDR techniques. The intent is to familiarize the reader 
with the functionality of some of the major components used in an IS-95B transceiver. 
Chapter V and VI show the details of the SDR transceiver design for implementing these 
components. 

1. Interleaver 

The interleaver used in the transmitter rearranges the order of the bits before 
transmission. In the IS-95B system, block interleaving is used where the data are divided 
into blocks or frames. The purpose of the interleaver is to disperse bursts of errors in 
time. If a burst of errors does occur during transmission, the deinterleaving process has 
the effect of producing a more random error pattern that can more easily be corrected by 


error correction techniques. [18] 


The sync channel uses a non-conventional interleaving technique that is described 


as bit reversal. Each sync channel frame consisting of 128 symbols is interleaved using a 
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bit reversal pattern as follows: The data entering the interleaver is read into an input array 
by columns, interleaved, and read out of the output array by columns. The decimal 
position of the data in the input array is converted to a seven digit binary value, the bits 
are reversed, and then the new binary value is converted back to decimal form. The data 
belonging in this decimal position is then placed in the original decimal position. For 
example, for symbol one with a binary value of OOO0001, reversing the order gives a 
binary value of 1000000 which is 64 in decimal form. Symbol 64 is then placed in 
symbol position one. This process continues for all 128 symbols. Appendix B shows an 
example of the contents of the input and output arrays used in the sync channel 


interleaving process. [18] 


The paging and traffic channels also use a bit reversal technique that replaces a 
row of symbols instead of a single symbol. Symbols are first placed into an input array 
consisting of 384 symbols each. The input array is best described as a 64 X 6 array and 
the data is read out of the input array one row at a time in a permuted order. As an 
example, the bit reversal pattern is as follows: for row one, the binary value is 000001. 
Reversing the order yields binary 100000, which when converted back to decimal form 
gives 32. Symbols belonging to row one of the 64 X 6 input array are replaced with 
symbols from row 32. This pattern repeats for all 64 rows of the input array. Appendix B 
shows an example of the contents of the input and output arrays used in the paging and 
traffic channel interleaving process. [18] 

2. Deinterleaver 

The deinterleaver used in the receiver uses similar concepts used by the 
interleaver to rearrange the channel symbols back into the correct order [18]. 

3. Frame Quality Indicator (Cyclic Redundancy Check) Generator 

All traffic channel frames at data rates above 4.8 kb/s have a frame quality 
indicator (CRC) used for error detection purposes at the receiver. A linear feedback shift 
register (LFSR) is used to calculate the frame quality indicator (FQI) for each frame. For 


IS-95B the LFSR encoder uses the following generator polynomial for the 14.4 kb/s data 


5 2 16 
rate: I+ +x +x 
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This is implemented with the following hardware LFSR configuration below in 


Figure 10. The switches are up for the first 264 bits and down for the last 16 bits [18]. 





Figure 10. Linear feedback shift register configuration for traffic channel (After [18]). 


4. Syndrome Detector 
A syndrome detector checks traffic channel data, one frame at a time, for 
errors. The syndrome detector for the mobile receiver is illustrated in Figure 11. This is 
essentially the same circuit used to create the CRC for each traffic channel frame in the 
transmitter. The registers are initially set to logic one. The switch is up for the first N bits. 
For the 14.4 kb/s traffic channel data rate, N = 280 bits. The switch then moves into the 
down position, and the contents remaining in the shift registers form the syndrome 


vector, S . [18] 


Received code 
vector 


Quotient 
for 
syndrome 


ee 


Figure 11. Syndrome detector (After [18]). 
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5. PN Sequence Generators Specified in IS-95B 
a. Long PN Sequence for Scrambling 
One long PN sequence generated by a 42-stage shift register is used to 


scramble paging and traffic channel data. The 42 degree characteristic polynomial is: 


ep mT 9" Md AS, 1G) Me LAT: op t20 A ina OM he OSG Od oe OS. O80 S ae8S' as 86) BT ; : ‘ 
fs(x) =1L4 x 4A 4K FXO EKO EK AK EK EKO AKO EKO EOE KAKO EKO EMO FXO 4K 4K 4K 





To distinguish each user’s data from other data, the code generated by the 42-stage 
register is masked with a 42-bit long code mask to produce a unique scrambling code. 
The 42-bit long code masks for the paging and traffic channels are illustrated in Figure 12 
and Figure 13. [18] 


41 32 31 0 


1100011000 Permuted ESN 


Figure 12. Public long-code mask for traffic channels (After [18]). 


ESN: electronic serial number for mobile receiver 
PCN: paging channel number 
PILOT_PN: PN offset for the forward CDMA channel 


41 24 23 21 20 9 8 0 


110001100110100000; PCN |000000000000 |PILoT_PN 


Figure 13. Paging channel long-code mask (After [18]). 





The 42-bit masks used are the first 42 bits of some shift of the long code 


sequence where the period of the PN sequence is 2” —1chips long. To generate this 
code, the generator uses the inverse of the characteristic polynomial shown below and 


uses a maximal shift register configuration (MSRG) as indicated in Figure 14. 


% 
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Figure 14. 42-stage long code PN generator (After [18]). 


For descrambling the paging and traffic channels in the mobile receiver, 
the same unique PN sequence must be generated. To do so, the sync channel provides the 
current state of the long PN code to the mobile receiver. The mobile receiver then uses 
the same 42-stage generator and associated masks to produce the unique PN sequence 


code used for descrambling. [18] 


b. Short PN Sequences for Quadrature Spreading 

IS-95B specifies two short PN sequences for spreading data from all 
channels. The characteristic polynomials for the in-phase channel and quadrature channel 
codes are taken from reference [18] and shown below. 
fi(x) = 1L4+x?4+x° 4x7 42° 4x42” and 
folx) = 14x txt 4x 4x? tx taxa x? tx? 


These two PN sequences are generated by 15 stage simple shift register generators 
(SSRGs) as outlined below: 


a5 


Figure 15. In phase PN sequence generator (After [18]). 





Figure 16. Quadrature PN sequence generator (After [18]). 


As mentioned earlier in this chapter, each IS-95B base station generates 
the same two PN sequences but with different offsets. The IS-95B standard specifies that 
each offset is a multiple of 64 chips. An additional chip is inserted in the PN sequence to 


give a total of 32, 768 chips in a period for a total of — =512 possible offsets. [18] 


6. Convolutional Encoder 


The convolutional encoder for IS-95B is a rate ~ = encoder with constraint 
n 


lengthy = 9. This is implemented with eight shift registers and two modulo-two adders 


as indicated in Figure 17. The number of states is 2*=256 and the generator 


polynomials are as follows [18]: 


Gl=1+D'+D°?+D?+D°+pD'+D° 
G2=1+D°+D'+pD*+D* 
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Figure 17. IS-95B forward link convolutional encoder (After [18]). 


ds Viterbi Decoder 

A Viterbi decoder is used for decoding the information data from the sync, 
paging, and traffic channels previously encoded using forward error-correction 
techniques. The decoder is implemented using the Viterbi algorithm invented by A.J 
Viterbi. The Viterbi decoders used for the traffic channel differs from the one used to 
decode the paging and sync channels because the sync and paging channels have no 
added tail bits. The traffic channel Viterbi decoder is capable of decoding one traffic 
channel frame at a time and also takes into account the puncturing pattern used in the 
transmitter. Dummy bits are inserted into the traffic channel before decoding to increase 
the data rate into the decoder from 19.2 ks/s to 28.8 ks/s and the traffic channel data rate 
out of the decoder is 14.4 kb/s. The Viterbi decoder designed for the sync and paging 
channels is a truncated decoder that uses a finite amount of memory to determine the 
decoded bit stream. Using a truncated decoder results in a delay due to the amount of 
memory require by the decoder before the first bit can be decoded. [18] 

8. Walsh Modulator 

Up to 64 channels can go through the Walsh modulation process where one of 64 
Walsh functions modulates (spreads) the information data at a chip rate of 1.2288 Mc/s. 


The spreading factor for spreading sync channel data is 256 and the spreading factor for 


| 


spreading paging and traffic channel data is 64. There are a number of ways to generate 
Walsh functions, the most common of which are by using Rademacher functions and 
Hadamard Matrices. This thesis uses a lookup table approach in creating the 64 Walsh 
functions necessary for Walsh modulation in the transmitter and correlation in the 
receiver. [18] 

9. Walsh Correlator 

The orthogonal principle of Walsh functions enables extraction of all signals 
intended for a particular mobile, and allows the mobile to reject all other signals [18]. 
Using this principle and referring back to Figure 9, the nth mobile receiver recovers its 
signal by using the correlation operation depicted in Equation (5) taken from reference 


[18]. 


Tw 
The decision statistic Zn = | [ re(t) + rs(0) A Wn(t) dt (4) 
0 


Tw 
Zale {] [ AoDo(t)W o(t) +... + AnDn(t)Wn(t) +... + Aes + Dos(t) + Woa(t) | Walt) a| + 


0 


Tw 
| | n(t)Wn(t) a| 
0 


Tw 
= V2 AnDa(t)Tw + 9 where n = | n(tWn(t) dt 


0 


and n(t) = additive white Gaussian noise 


F. OTHER IMPORTANT CONCEPTS RELATED TO IS-95B FORWARD 
LINK 


1. PN Code Acquisition and Tracking 

The mobile receiver can only demodulate incoming channel data by knowing the 
exact code phase of the short PN sequences generated by the base station. The mobile 
receiver determines this code phase by performing a correlation operation between the 
received signal and a locally generated PN code sequence. The mobile receiver 
determines if the two code phases match by observing the autocorrelation peak of the 
correlation operation. This correlation occurs over a period of 32 chips. If the mobile 


receiver does not obtain an acceptable autocorrelation peak, it continues searching for the 
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correct code phase by performing more autocorrelation calculations in periods of 32 
chips. Once the code phase is acquired and successful synchronization between PN 
sequences is determined, the timing reference is established. To keep track of the 
incoming code phase to maintain and achieve a timing error of zero, a delay-lock loop 
(DLL) is used. Furthermore, the mobile receiver uses phase-lock loop (PLL) techniques 


to determine the carrier frequency and phase. [18] 


Due to timing constraints and the high degree of complexity involved with 
designing and building PN acquisition and PN code tracking components, these topics 
will not be considered in this thesis and are suggested as follow on work in future designs 


of an IS-95B SDR transceiver. 
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IV. DESIGN METHODOLOGY 


A. SYSTEMS ENGINEERING DESIGN PROCESS 

To assist with the development and design of the IS-95B transceiver system, a 
top-down systems engineering approach was implemented, because such an approach 
enables the design of a system where requirements are always satisfied through every 
step of the design process. A top-down approach also allows partitioning of the 
transceiver system into smaller elements, enabling the development, design, and testing 
of different elements of the system without affecting the entire system as a whole. 
Furthermore, the top-down systems engineering process allows us to identify the “whats” 
through the use of functional terms and requirements, followed by translating these 
“whats” into a set of “hows.” The “whats” in the transceiver design relate to the 
functionality of each component in the design and the “hows” correspond to the 


implementation of each component using software techniques. [19] 


Below is an adaptation of the “VEE” systems engineering process model used for 


the transceiver design [19]. 





Solution 


Figure 18. | VEE Process Model (After [19]). 
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The “VEE” Model starts with user needs on the upper left and ends with a user- 
validated system on the upper right. On the left side, the system requirements are 
identified by system needs, and these requirements are translated into a set of design 
requirements. Once the design requirements are determined, the actual design and 
building of the system components is accomplished. Moving along to the right of the 
“VEE” model, the next step calls for extensive testing to ensure the components perform 
and meet system specifications and requirements. Next, integration of system 
components occurs where components are linked together and further testing is 
accomplished. Once testing is complete, the overall design is verified to ensure all design 
requirements have been met. Finally, the last step is the validation of the complete system 
by verification of a satisfactory system that meets all requirements. The following section 
outlines the details for using the “VEE” process model for the transceiver design. [19] 

1. Requirements and Sub-system Allocation 

First, the main requirements of the system being built are developed. The focus is 
to establish a set of requirements for the IS-95B transceiver communications system we 
want to implement. The requirements developed for the transceiver system are listed 


below. 
e The system must be able to transmit and receive IS-95B signals 


e The system must have the capability to interface with the hardware portion 


of a radio transceiver 


e The system must be built with software components that meet the 


requirements of the SCA 


e The system must be built with as little complexity as possible to allow for 


ease of testing, data processing, and reconfiguration 


Once the requirements were determined, it became necessary to identify the sub- 
systems for implementing the desired system along with the required functions of these 
sub-systems. These sub-systems are simply the transmitter and the receiver. Once we 
identify our sub-systems, it is necessary to allocate functional requirements for them. 


These functional requirements are somewhat related to a set of requirements normally 
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needed to implement the IS-95B physical layers of a typical IS-95B base station 
transmitter and corresponding mobile receiver. These requirements are referenced from 


[16] and listed in Table 3. 














Bandwidth 1.25 MHz 

Chip Rate 1.2288 Mcps 

Frequency band uplink 869-894 MHz 
1930-1980 MHz 

Frequency band downlink 824-849 MHz 
1850-1910 MHz 

Frame length 20 ms 

Bit rates Rate set 1: 9.6 Kb/s 


Rate set 2:14.4 Kb/s 
IS-95B: max 115.2 Kb/s by bundling up to eight channels 




















Speech code QCELP 8 Kb/s\ 
ACELP 13 kb/s 
Soft handover Yes 
Power control Uplink Open loop + fast closed loop 
Downlink: slow quality loop 
Number of Rake fingers 4 
Spreading codes Walsh + Long M sequence 





Table 3. IS-95B air interface functional requirements (From [16]. 


Table 3 is used as a benchmark for developing the sub-system functional 
requirements. However, we can only develop requirements that can be implemented with 
software. Hence, we will assume that all other requirements stated in Table 3 that will not 
be implemented in software will be implemented with appropriate hardware. Table 4 lists 
the corresponding sub-system functional requirements developed for the design of the 
SDR transceiver. These design requirements are realistic enough to implement the 


functionalities of a typical radio transceiver for an IS-95B communications system. 
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Transmitter 


Receiver 





Simulate the forward link channel of IS-95B 
system with transmission of data from base 
station to mobile 


Transmit up to 64 orthogonal code division 
multiplexed signals. 


Build receiver to recover an  IS-95B 
communication waveform transmitted by a 
base station 


Perform data signal processing using baseband 
data 





Simulate four distinct channels: pilot, sync, 
paging, and traffic channels 


Extract pilot, sync, paging, and traffic channel 
message data from orthogonal code division 
multiplexed signal 





Perform data signal processing using baseband 
data 


Process data at a minimum rate of 1.2288 Mc/s 





Process data at a minimum rate of 1.2288 Mc/s 


Process data in frames of 20 ms in length 





Process data in frames of 20 ms in length 


Build system with reconfigurable software 

















components 
Build system with reconfigurable software | Build system with reusable software 
components components 
Build system with reusable software 
components 
Table 4. Functional requirements of sub systems (After [16] [18]). 
2; Software Component Determination 


The next step of the systems engineering process requires the identification of the 
many individual software components needed to implement the physical layers of an IS- 
95B transmitter and receiver. For both the transmitter and receiver, several individual and 
independent software components are required to design a complete system capable of 
effectively generating and recovering the IS-95B communication waveforms. Since the 
IS-95B system is an already established standard [16], the physical layers of the IS-95B 
base station forward link system are used to identify the functional software components 
required in meeting all the functional requirements stated in Table 4. By using OWD, all 
the physical layer components of a hardware based IS-95B transceiver are translated into 
software components. These software components can be designed to perform functions 
equivalent to functions performed by one or more of the components of a hardware based 
IS-95B system. Although software based components are quite capable of performing 
multiple functions, all attempts are made to make each software component as simple as 
possible to allow fairly straight forward programming, testing, and debugging, as well as 


allow for reusability by other communication waveforms. The translation of physical 
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layer hardware components to software components for this design is illustrated by block 
diagrams in chapter V for the transmitter and chapter VI for the receiver. 

3. Design and Build Components 

After determining what software components will be needed, the detail design and 
building of the components can begin. Designing the components involves writing 
algorithms to implement the functionality of each software component and then 
translating these algorithms into C++ code. 

4. Testing, Verification, and Complete System Validation 

The process model further allows us to test our components individually and as 
part of a complete system. Once individual components have been tested successfully, we 
can perform integration with other components, followed by a complete system test to 
verify that our design is working successfully. The benefit of using the systems 
engineering process model is that individual components can be tested separately without 
affecting the whole system. More complex software components that require extensive 
testing can be set aside and worked on at a later time, while allowing the development 
and testing of simpler software components to continue. Another benefit of the systems 
engineering process model is the ability to check that the system built meets all the 
requirements and if these requirements are not met, to go back through earlier steps in the 


design process to ensure that all requirements can be met. 


Once testing is complete, the design is verified by checking that all sub-systems 
perform in accordance to expectations outlined in the sub-system functional 
requirements. If these requirements have not been met, we need to make the necessary 
changes to try to get our sub-systems to meet all the requirements. If all the requirements 
can not be met, then we simply state the reasons why and we accept the performance of 
the sub-systems. The final stage of the systems engineering process involves the 
validation of the product (transceiver). To validate, we check that the final product 
produced meets all the main requirements stated at the beginning of the systems 


engineering process. 


Overall, the systems engineering model is a tool that allows the software radio 
based IS-95B transceiver system to be developed and tested in a systematic, organized, 


and efficient manner. 
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B. SOFTWARE COMPONENTS DESIGN 

1. General Component Description 

Each component accepts data via one or more provides ports and the data is sent 
to the process_data method for processing [3]. A method in C++ programming is 
analogous to a function in C programming. Each provides port is defined by an interface 
according to the type of data the port needs to support. For this thesis only short and float 
data types were considered. Short data types represent integers and float data types 
represent real numbers. A single input provides port uses the realShort interface for short 
data types and the realFloat interface for float data types. A dual input provides port uses 
the ComplexShort interface for short data types and ComplexFloat interface for float data 
types. . The process_data method is responsible for all data processing. All data entering 
a component is first copied and stored in a data buffer within the process_data method. 
The process_data method then processes the data by calling one or more processing 
methods. The processing of data is done in a sequential fashion by calling one processing 
method at a time as indicated in Figure 19. When all processing methods complete their 
tasks, the process_data method copies the processed data into a buffer and sends the data 
to the next component via one or more uses ports by calling the send_data method [3]. 
Each uses port is also defined by an interface according to the type of data the port needs 
to support. The designation for the uses ports follows the same convention used for 
describing the provides ports. A single input uses port uses the realShort interface for 
short data types and the realFloat interface for float data types. A dual input uses port 
uses the ComplexShort interface for short data types and the ComplexFloat interface for 
float data types. The processing of data into and out of a component for a single input 


provides port and a single output uses port is illustrated in Figure 19. 
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External 


Data enters via 
provides port 


Process_data Method 


Data exits via 
uses port 





Figure 19. General component description. 
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2% Component Features 
In addition to the standard features that OSSIE Waveform Developer includes in 

all its components, a few additional features were added for this project. 

a. Header files: IS-95B_TX_library.h, IS-95B_RX_library.h 

Each component has access to a header file containing a list of global 
attributes (variables). The components belonging to the transmitter have access to the IS- 
95B_TX_library.h file and the components belonging to the receiver have access to the 
IS-95B_RX_library.h file. These global attributes can be changed depending on user 
specifications. The library files initialize the attributes directly related to each component. 
Users of these components have the benefit of easily reconfiguring the software 
components by directly changing the attribute values in the header files. For example, the 
length of an incoming channel can be changed as well as the number of channels being 
processed at any one time. In addition, the library files allow the data type of each 
attribute to be changed easily, say from a short data type to a float data type. 

b. Methods 

Each component consists of a number of methods (functions) used to 
process data as well as control the flow of data into and out of a component. The 
components are designed to allow ease of reconfiguring the radio functionalities via 
modifying the current processing methods and/or inserting or removing methods, thus 
allowing for the benefits of using a software radio design. Two standard methods are 


included in each component: process_data and send_data. 


The function of these two methods were briefly stated earlier and repeated 


here for emphasis. 


process_data: This method is used to process incoming data by calling one or more 


methods (functions) [3]. 


send_data: This method is used to send processed data from one component to the next 


component [3]. 


The next two chapters describe the details of the design and functions of 


the transmitter and receiver components. 
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V. TRANSMITTER DESIGN AND DEVELOPMENT 


A. INTRODUCTION 

The transmitter for this design will create signals that closely resemble signals 
produced by an IS-95B base station transmitter. As mentioned in Chapter III a base 
Station transmitter can transmit up to 64 channels on one frequency assignment [18]. 
Replicating an entire base station to produce up to 64 channels is a tedious task. The main 
purpose for designing the transmitter is to produce a signal that can be recovered and 
demodulated by an IS-95B mobile receiver. Taking this into account, we only need to 
replicate a few channels in order to produce a signal that is testable by our receiver. The 
transmitter design will then focus on creating an IS-95B signal consisting of at least four 
channels: one pilot channel, one sync channel, one paging channel, and one traffic 
channel. Since the transmitter is built using SDR techniques, it will have the ability to 
reconfigure itself to add more channels if needed, but adding more channels is not 


necessary for proving that the transceiver design works. 


B. TRANSMITTER BLOCK DIAGRAM 

For the transmitter, we can translate the components found in the block diagram 
of the physical layer of an IS-95B forward link base station transmitter shown in Chapter 
Ill, Figure 8 from reference [16] into a software based radio design block diagram as 
outlined in Figure 20. Each software component performs the function of one or more 


components found in the IS-95B hardware implementation. 
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Pilot channel data Pilot channel data 


Sync channel data Sync channel data 
Paging channel data Paging channel data 
Traffic channel data Traffic channel data 
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Sync channel data Sync channel data Sync channel data Sync channel data 
Paging channel data Paging channel data Paging channel data Paging channel data 
Traffic channel data Traffic channel data Traffic channel data Traffic channel data 


Figure 20. Transmitter Component Block Diagram. 


A total of eight components were used to implement the transmitter. Table 5 lists 
the components used to build the transmitter with each corresponding function. A 
description of these components follows later in this chapter but a few design 


considerations must be addressed before proceeding. 





























COMPONENT FUNCTION 

CRC Adds parity bits to all traffic channel 
frames 

Convolutional encoder Encodes all channels with rate /2 code (3/4 
for traffic channel due to puncturing 

Symbol repetition Repeats symbols for sync channel 

Interleaver Interleaves channel symbols 

LongPN Scrambler Scrambles paging and traffic channel data 

Walsh Modulator Modulates channels with Walsh sequences 

Quadrature Spreader Modulates channel data with In phase and 
Quadrature PN codes 

Multiplex channels Multiplexes all I & Q channels into single I 
& Q channels 





Table 5. Transmitter Components. (After [18]). 
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C. DESIGN CONSIDERATIONS 

1. Operational Mode 

The transmitter is initially designed for single mode operations to process data to 
facilitate a maximum data rate of 14.4 kb/s. Provisions for changing the mode to operate 
at different data rates were also considered. 

2. Real Time Processing 

Since our transmitter is built using a general purpose processor, the data generated 
by the transmitter will be created and processed at a rate equivalent to the processing 
speed of the general purpose processor. An assumption is made that if our transmitter was 
built with a RF hardware interface included, there would be controls and buffers in place 
to control the data rate out of the transmitter to the IS-95B data rate. 

3. Power Control Bits 

The design of the transmitter will not include adding power control bits to the 
traffic channel, since we are only implementing the forward link of an IS-95B system. 
We mentioned in Chapter III that power control bits are added to the traffic channel to 
alert the mobile receiver to increase or decrease power when transmitting data on the 
reverse link. Since we are only focusing on the forward link, we do not need to 
implement this function in our transmitter. Furthermore, our receiver will not implement 
functions for checking power control bits in received traffic channel data. We 
recommend, however, that future SDR designs for an IS-95B reverse link (uplink) 
communications system provide software components for performing features to add 
power control bits to traffic channel data in the transmitter and also to check power 


control messages in the receiver. 


D. TRANSMITTER DATA FLOW 

For this design it became necessary to determine how exactly the software 
components would process the baseband digital data. Since the data processing rate of a 
SDR is usually limited by the hardware being used (GPP, FPGA, ASIC, etc), we make 
the assumption that our software radio design can be tailored to meet the data rate of an 
IS-95B system. With this in mind, we have to establish a way for the software 


components to process data regardless of the data rate required out of the transmitter. 
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To facilitate data processing in an efficient manner, the data for the channels is 
separated by frames in each component, and processed according to the number of frames 
per channel at any given time. For IS-95B at rate set two, a sync channel frame contains 
32 bits, a paging channel frame has 192 bits, and a traffic channel frame has 264 bits. 
After encoding by the convolutional encoders, the sync channel has a data rate of 2.4 
kb/s; the data rate for the paging channel is 19.2 kb/s and the data rate for a traffic 
channel is 19.2 kb/s. The sync channel bits are then repeated to produce 4.8 ks/s and the 
ratio between sync channel bits to paging and traffic channel bits is four to one. The bits 
are further processed at this four to one ratio until reaching the Walsh modulator 
component where the channel symbols are modulated by Walsh chips at a chip rate of 
1.2288 Mc/s. [18]. With these bit ratios in mind for the different channels, we can tailor 


our software components to facilitate processing data in an efficient manner. 


Each component accepts a set of data of a predetermined size, processes the data, 
sends the data to the next component, and then accepts another set of data. At any given 
time a component is capable of processing one sync channel consisting of three frames, 
X number of paging channels with four frames each , and N number of traffic channels 
with four frames each, where X is from one up to eight and WN is from one up to 55 
[18]. An IS-95B base station transmitter normally generates up to eight paging channels 
and 55 traffic channels [18]. For this design, only one paging channel and one traffic 
channel will be generated, but the transmitter will be built with the ability to add more 
channels. Table 6 illustrates the amount of data processed by each component at one 
time. Each column lists the component name and the rows are separated by channel type 
(pilot, sync, paging, traffic) and indicate the amount of data entering and leaving each 


component from each channel. 
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COMPONENT 
CHANNEL 
Sync channel 
Paging channel 
Traffic channel 
Pilot channel 


CRC cony encoder Symbol repetition 
a) ed |) |) 


COMPONENT 
CHANNEL 
Sync _channel 
Paging channel 
Traffic channel 

COMPONENT | Quadrature Spreader | Multiplex channels | | 
CHANNEL dataout,c| datain,c| dataout,c| «| Cd 
Syne channel 93304] 98304 gaszo4|NA | CTCCSCidC 
Paging channel 98304 98304 geso4(NA TT 
Traffic channel 98304 98304 gasoa(n TCT 
Pilot channel 93304] 98304! gaszo4|NA | CT CCCidC 
Sin) INA IACI CTC Os] CCCCidC 
b-bits 
s-symbols 
c-chips 
S(n) -- multiplexed orthogonal baseband signal 

Table 6. Transmitter data flow. 


E. TRANSMITTER COMPONENT DESCRIPTIONS 

The software components belonging to the transmitter block diagram from Figure 
20 will now be described. Diagrams showing the flow of data into and out of a 
component are also shown. These diagrams follow the same convention used to describe 
a component in Chapter IV, Figure 19. All components are designed in a similar fashion. 
First, data entering a component is copied by the process_data method and stored in a 
buffer. The process_data method then processes the data by calling one or more 
processing methods. After the data has been processed, the process_data method copies 
the data into a buffer and then sends the data to the next component by calling the 
send_data method. Each component assumes a naming convention with the suffix title 
IS95B to distinguish it as a component designed for an IS95B system. This naming 
service is used mainly for identification and organization purposes and does not prevent 
the use of the components in other waveforms. 

1. CRC 

Component Name: CRC_IS95B 


Port descriptions: Component has one uses and one provides port. Both ports are 


of type realShort 
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Function: This component is responsible for appending 16 bit parity code to end 
of each traffic channel frame [16] as explained in Chapter III. Incoming data from all 
channels (sync, paging, and traffic) is first copied by the process_data method. The 
process_data method then processes the data by calling the following processing 
methods: Separate_Channels, Add_paritycheckbits, and Combine_Channels. Once the 
data is processed, the process_data method calls the send_data method to send the data 
to the next component. Functional description of this component is illustrated in Figure 


21. The tasks of the processing methods used in this component are described in Table 7. 


Processing method Provides port Uses port 


_— eee | [room ra 
Name of Method 
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Sync channel 
Paging channel 
Traffic channel 


Process_data Method 





Figure 21. 





Convolutional_encoder_IS95B 


CRC_IS9SB. 





PROCESSING METHOD 


TASK 





Separate_Channels 


This method separates incoming data into 
sync, paging, and traffic channels 





Add_paritycheckbits 


This method appends 16 bit parity code to 
end of traffic channel frames 








Combine_Channels 





This method combines channels into one 
data stream 





Table 7. | CRC_IS95B processing methods tasks. 


Qs Convolutional Encoder 


Component Name: Convolutional_encoder_IS95B 


8) 











Port descriptions: Component has one uses and one provides port. Both are of 


type realShort. 


Function: This component encodes channel bits using rate ¥2 code for sync and 
paging channels and rate *%4 punctured code for traffic channels [16] as explained in 
Chapter II]. The incoming data is first copied by the process_data method. The 
process_data method then processes the data by calling the following processing 
methods: Separate_Channels, Encode_TrafficData, Encode_ChannelData, and 
Combine_Channels. Once the data is processed, the process_data method calls the 
send_data method to send the processed data to the next component. Description of this 


component is illustrated in Figure 22. The tasks of the processing methods used in this 


component are described in Table 8. 


CRC_IS95B 


Process_data Method 


( suter(_) Separate_Channels 


Sync channel Paging channel traffic channel 


Encode_TrafficData 


Traffic channel 















Encode_ChannelData 





Sync channel 


Combine_Channels 


Paging channel 

















Symbol_repetition_IS95B 





Figure 22. Convolutional_encoder_IS95B. 
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PROCESSING METHOD 


TASK 





Separate_Channels 


This method separates incoming data into 
sync, paging, and traffic channels 





Encode_ChannelData 


This method encodes sync channel data and 
paging channel data using a rate ¥2 encoder 





Encode_TrafficData 


This method encodes traffic channel data 
using a rate ¥2 encoder and then punctures 
the encoded data to produce an effective 
encoded rate of %4 








Combine_Channels 





This method combines channels into one 
data stream 





Table 8. | Convolutional_encoder_IS95B processing methods tasks. 


3. Symbol Repetition 


Component Name: Symbol_repetition_IS95B 


Port descriptions: Component has one uses and one provides port. Both are of 


type realShort. 


Function: This component repeats incoming sync channel symbols changing sync 


channel data rate from 2.4 ks/s to 4.8 ks/s [18]. This component is also capable of 


repeating other channel information if necessary to increase the data rate of the channel. 


The incoming data is first copied by the process_data method. The process_data method 


then processes the data by calling the following processing methods: Separate_Channels, 


Symbol_repetition, and Combine_Channels. Once the data is processed, the process_data 


method calls the send_data method to send the processed data to the next component. 


Functional description of this component is illustrated in Figure 23. The tasks of the 


processing methods used in this component are described in Table 9. 
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Convolutional_encoder_IS95B 


Process_data Method 














Interleaver_IS95B 


Figure 23. Symbol_repetition_IS95B. 














PROCESSING METHOD TASK 

Separate_Channels This method separates incoming data into 
sync, paging, and traffic channels 

Symbol_repetition This method repeats sync channel data 

Combine_Channels This method combines channels into one 
data stream 








Table 9. | Symbol_repetirion_IS95B processing methods tasks. 


4. Interleaver 


Component Name: Interleaver_IS95B 


Port descriptions: Component has one uses and one provides port. Both are of 


type realShort. 
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Function: This component interleaves incoming channel data as explained in 
Chapter III. Sync channel data is interleaved in blocks of 128 symbols and paging and 
traffic channel data is interleaved in blocks of 384 symbols each [18]. The incoming data 
is first copied by the process_data method. The process_data method then processes the 
data by calling the following methods: Separate_Channels, Interleave_SyncChannel, 
Interleave_Channel, and Combine_Channels. Once the data is processed, the 
process_data method calls the send_data method to send the processed data to the next 
component. Functional description of this component is illustrated in Figure 24. The tasks 


of the processing methods used in this component are described in Table 10. 





[ S»mbotsepeiton 18958 








Process_data Method 





LongPN_Scrambler_IS95B 


Figure 24. Interleaver_IS9SB. 
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PROCESSING METHOD TASK 











Separate_Channels This method separates incoming data into 
sync, paging, and traffic channels 

Interleaves_SyncChannel This method interleaves sync channel data 
in blocks of 128 symbols as described in 
Chapter III 

Encode_TrafficData This method interleaves paging channel 


and traffic channel data in blocks of 384 
symbols as described in Chapter III 








Combine_Channels This method combines channels into one 
data stream 








Table 10. Interleaver_IS95B processing methods tasks. 


5. LongPN Scrambler 
Component Name: LongPN_Scrambler_IS95B 


Port descriptions: Component has one uses and one provides port. Both are of 


type realShort. 


Function: This component independently scrambles paging and traffic channel 
data using long PN code sequence specified in Chapter III. The initial state of the PN 
code generators is initially determined by a value obtained as a parameter within this 
component. The encoder state is then continuously updated and stored in memory. The 
LongPN_Scrambler_IS95B component retrieves the current state of the generator from 
memory whenever the generator is initialized. The incoming data is first copied by the 
process_data method. The process_data method then processes the data by calling the 
following processing methods: Separate_Channels, Initialize_GEN, Scramble_Data, and 
Combine_Channels. Once the data is processed, the process_data method calls the 
send_data method to send the processed data to the next component. Functional 
description of this component is illustrated in Figure 25. The tasks of the processing 


methods used in this component are described in Table 11. 
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Process_data Method 
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Paging channel 


Scramble_Data 


Paging channel 
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Traffic channel 
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Walsh_Modulator_IS95B 





Figure 25. 


LongPN_Scrambler_IS95B. 





PROCESSING METHOD 


TASK 





Separate_Channels 


This method separates incoming data into 
sync, paging, and traffic channels 





Initialize _ GEN 


This method initializes the long code PN 
sequence generator and creates long code 
PN sequence values for scrambling paging 
and traffic channel data 





Scramble_Data 


This method scrambles paging channel and 
traffic channel data by multiplying long 
code PN sequence with channel data 





Combine_Channels 








This method combines channels into one 
data stream 





Table 11. 
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LongPN_Scrambler_IS95B processing methods tasks. 





6. Walsh Modulator 
Component Name: Walsh_Modulator_IS95B 


Port descriptions: Component has one uses and one provides port. Both are of 


type realShort. 


Function: This component modulates and spreads channel data by using Walsh 
sequences as described in Chapter HI. Up to 64 channels can be modulated by up to 64 
independent Walsh sequences [18]. Walsh sequences are selected from a look up table. 
This component also creates the pilot channel consisting of all binary zeros [18]. The 
incoming data is first copied by the process_data method. The process_data method then 
processes the data by calling the following processing methods: Separate_Channels, 
Walsh_selection, Spread_SyncChannel, Spread_PgandTraffic_Channels, 
Create_PilotChannel and Combine_Channels. Once the data is processed, the 
process_data method calls the send_data method to send the processed data to the next 
component. Functional description of this component is illustrated in Figure 26. The tasks 


of the processing methods used in this component are described in Table 12. 
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Process_data Method 





Quadrature_Spreader_IS95B 


Figure 26. Walsh_Modulator_IS95B. 
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PROCESSING METHOD TASK 








Separate_Channels This method separates incoming data into 
sync, paging, and traffic channels 
Walsh_selection This method assigns Walsh sequences to 


the sync, paging, and traffic channels as 
explained in Chapter Ill. The Walsh 
sequences are extracted from a look up 
table 





Spread_SyncChannel This method spreads sync channel data 
with a spreading factor of 256 by 
multiplying Walsh sequence, H32, with 
sync channel data 





Spread_PgandTraffic_Channels This method spreads paging channel and 
traffic channel data with a spreading factor 
of 64 by multiplying appropriate paging 
channel or traffic channel Walsh sequence 
with paging or traffic channel data 








Create_PilotChannel This method creates pilot channel data 
Combine_Channels This method combines channels into one 
data stream 








Table 12. © Walsh_Modulator_IS95B processing methods tasks. 


Vs Quadrature Spreader 


Component Name: Quadrature_Spreader_IS95B 


Port descriptions: This component has one uses and one provides port. Uses port 


is of type complexShort and provides port is of type realShort. 


Function: This component quadrature spreads channel data by using in phase and 
quadrature short PN code sequences as described in Chapter III. The component is 
capable of generating any one of 512 possible PN sequences as determined by the 
possible 512 offsets used by an IS-95B base station transmitter [18]. The incoming data 
is first copied by the process_data method. The process_data method then processes the 
data by calling the following processing methods: _Initialise_ShortPNI, 
Initialise_ShortPNQ, and Spread_data. Once the data is processed, the process_data 
method calls the send_data method to send the processed data to the next component. 
Functional description of this component is illustrated in Figure 27. The tasks of the 


processing methods used in this component are described in Table 13. 
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Walsh_Modulator_IS95B 











Process_data Method 








Figure 27. 





Multiplex_channels_IS95B 


Quadrature_Spreader_IS95B. 





PROCESSING METHOD 


TASK 





TInitialise_ShortPNI 


This method initializes short in-phase PN 
sequence generator and creates in-phase PN 
sequence values for spreading channel data 





Initialise_ShortPNQ 


This method initializes short quadrature PN 
sequence generator and creates quadrature PN 
sequence values for spreading channel data 








Spread_data 





This method independently spreads channel 
data with in-phase and quadrature PN 
sequences 








Table 13. Quadrature_Spreader_IS95B processing methods tasks. 
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8. Multiplex Channels 
Component Name: Multiplex_channels_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type complexShort 


Function: This component multiplexes (adds) all in phase and all quadrature 
channels to produce a single in-phase and a single quadrature channel [18]. The 
incoming data is first copied by the process_data method. The process_data method then 
processes the data by calling the following processing method: Multiplex_channels. Once 
the data is processed, the process_data method calls the send_data method to send the 
processed data to the next component. Functional description of this component is 
illustrated in Figure 28. The task of the processing method used in this component is 
described in Table 14. After data is processed by this component, the data would 
normally be sent to other software components where digital filtering and sample rate 
conversion (interpolation) processes would occur. Digital filtering involves filtering the 
baseband data samples to change the frequency of the signal or could also involve 
filtering the baseband samples using a pulse shaping digital filter. Interpolation is the 
process of increasing the number of samples per unit time used to describe a signal [2]. 
The filtered and interpolated data would then be sent to the RF front end of the radio for 


upconversion to the carrier frequency and amplification. 


66 





Quadrature_Spreader_IS95B 














Process_data Method 


Multiplex_channels 





In-phase data Quadrature data 


Buffer Buffer 















Figure 28. 








| Digital filter/Interpolator | 





Multiplex_channels_IS95B. 





PROCESSING METHOD 


TASK 





Multiplex_channels 


This method independently adds in-phase 
pilot, sync, paging, and traffic channels, 
and quadrature pilot, sync, paging, and 
traffic channels, producing a single in- 
phase and a single quadrature channel 








Table 14. 


Multiplex_channels_IS95B processing method tasks. 
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F. ALGORITHM DEVELOPMENT 

Algorithms are useful for designing software components because they enable a 
SDR designer to develop a conceptualized way of implementing a component by writing 
out a set of instructions in plain English or developing a flow chart to aid in the 
programming process. Writing code to implement each of the transmitter components can 
be a long, tedious task. By using an algorithm the code is much easier to develop. Several 
algorithms were derived before writing C++ code to implement the functionality of the 


transmitter components. 


G. CODE DEVELOPMENT 

After developing algorithms for the transmitter components, the functionality of 
each component was implemented by writing useful C++ code. Some of the components 
used algorithms and C++ code from external sources, specifically, the Quadrature 
spreader and convolutional encoder components. The quadrature spreader component 
uses an algorithm derived by converting Matlab code introduced by Harada and Prasad 
into C++ code [20]. The convolutional encoder component was developed using similar 
C++ code found on a tutorial from a website called “IT++” [21]. This website became a 


valuable source for finding resources on C++ code for communications systems. 


1. IT++ 

IT++ is an open source signal processing library based on C++. The library 
contains communications, mathematics, signal processing, and speech processing classes 
and functions. The IT++ library was downloaded from the internet and used as an aid in 
developing some of the components for the transceiver. Some of the useful 
communications sources available are classes and methods (functions) for implementing 
interleavers, convolutional encoders, Viterbi decoders, finite impulse response filters, and 
various modulation schemes, such as binary phase shift keying and orthogonal frequency 
division multiplexing [22]. There is a learning curve when using this library, but the 
benefits can be huge when trying to implement communication components using 


software. 
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VI. RECEIVER DESIGN AND DEVELOPMENT 


A. INTRODUCTION 

For this design, we took into consideration design requirements from reference 
[16] and [18]. Every attempt is made possible to make the receiver function the same as 
an actual IS-95B receiver. Only the physical layers of an IS-95B receiver will be 
implemented in this design. The main goal is to recover information bits from the 
received baseband signal produced by the transmitter. The design of the receiver 
incorporated the need to build simple, reusable, and reconfigurable software components 
with the intent that many components may be needed to allow the receiver to perform in 


the most reliable and efficient manner. 


B. RECEIVER BLOCK DIAGRAM 

Similar to the transmitter, the physical layer of an IS-95B forward link mobile 
receiver is replicated to implement the functional parts required to meet the given 
requirements for an IS-95B receiver. The software radio design block diagram for the 
receiver is outlined below in Figure 29 where each block represents one software 
component. Each software component performs the function of one or more components 
found in an IS-95B hardware implementation. The design of the receiver differs 
somewhat from the transmitter because the intention for the receiver design is to have the 
capability to distinguish the different types of channels being received, and to demodulate 
these channels using separate components wherever feasible. The received signal does 
goes through the first two software components, Quadrature Despreader and Walsh 
Correlator. Once the signal reaches the Walsh Correlator component, the receiver already 
knows which channel it wants to demodulate and the Walsh_Correlator component 
receives a message stating which channel it should demodulate. The pilot channel is used 
by the receiver for PN code acquisition and tracking of the two short PN codes used in 
the transmitter. These functions are performed before demodulation of any other channels 
can occur [16]. These functions will not be considered in this transceiver design. Hence, 
we will assume that the receiver is already synchronized with a corresponding 


transmitter. In this case, we will use the transmitter design from Chapter V. The Walsh 
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Correlator component extracts the desired channel data (sync, paging, or traffic) and 


sends the channel data through the appropriate set of software components for 


demodulation. As indicated in Figure 29, the sync, paging, and traffic channel 


demodulation paths in the receiver may be considered separated by switches, such that 


only one switch is closed at any time to allow demodulation of one specific channel type 


only. 








sync channel normalizer 













sync channel deinterleaver 







Symbol removal 


sync channel decoder 


Figure 29. 


Baseband data 


Quadrature Despreader 
Walsh Correlator 


paging channel normalizer 
paging channel descrambler 











paging channel deinterleaver 


paging channel decoder 


Receiver component block diagram. 
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traffic channel normalizer 





traffic channel descrambler 
traffic channel deinterleaver 


traffic channel decoder 





syndrome detector 


A total of 15 components are used to implement the receiver. Table 15 lists the 


components used to build the transmitter with each corresponding function. A description 


of these components follows later in this chapter but a few design considerations must be 


addressed before proceeding. 








Walsh_Correlator 


COMPONENT FUNCTION 
Quadrature_Despreader Despreads channel data 


Extracts any of 64 possible channels from 
incoming CDMA channel 





Sync channel normalizer 


Normalizes decision statistics out of Walsh 
Correlator 





Sync channel deinterleaver 


Deinterleaves sync channel symbols 





Symbol removal 
Sync channel decoder 
Paging channel normalizer 


Paging channel descrambler 


Removes duplicate symbols from sync 
channel 

Decodes sync channel data to recover 
information bits 

Normalizes decision statistics out of Walsh 
Correlator 

Descrambles paging channel data 





Paging channel deinterleaver 


Deinterleaves paging channel symbols 





Sync channel decoder 


Decodes paging channel data to recover 
information bits 





Traffic channel normalizer 


Normalizes decision statistics out of Walsh 
Correlator 





Traffic channel descrambler 
Traffic channel deinterleaver 


Descrambles traffic channel data 
Deinterleaves Traffic channel symbols 





Traffic channel decoder 


Decodes traffic channel data to recover 
information bits 








Syndrome detector 


Checks traffic channel frames for errors 











Table 15. Receiver components. 


C. RECEIVER LIMITATIONS 

1, Operational Mode 

Similar to the transmitter, the receiver is designed for single mode operations to 
process data to allow transmission of IS-95B signals with a maximum data rate of 14.4 
kb/s [16]. Provisions for changing the receiver to operate in different modes were also 
considered, but the receiver was first designed to operate in a single mode. 

2. Real Time Processing 

For this thesis, the receiver software was implemented on the general purpose 


processor in a computer and interfacing this software with live RF signals is left for 
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future work. Since the receiver will not interface with any hardware, the data processing 
rate of the receiver depends on the processing speed of the general purpose processor 
being used. An assumption is made that if our receiver was built with an RF hardware 
interface included, there would be controls and buffers in place to control the data rate to 
the IS-95B data rate. 

3. Channel Assignments 

Receiver is not capable of switching channel assignments. Channel assignments 
are predetermined and set by the user. Future design considerations might include adding 
a software feature with the capability of changing channel assignments as needed by 
completely decoding incoming sync channel and paging channel data, but this is a 


function beyond the physical layer. Hence, this is not considered for this design. 


D. RECEIVER DATA FLOW 

It is also necessary to consider the flow of data from one component to the next in 
the receiver. Again assuming that a suitable RF front end can match the data rate required 
for an IS-95B receiver, we can develop the receiver components to process the incoming 
data appropriately. For the receiver, the assumption is made that each component accepts 
a set of data of a predetermined size, processes the data, sends the data to the next 
component, and then accepts another set of data, regardless of the incoming data rate. For 
this design, we simply allow the components to process data in a similar manner to the 
design of the transmitter. The pilot channel data does not get demodulated, so the main 
focus here is to discuss the other types of channels that can be received and demodulated. 
Referring to Figure 29, each component associated with demodulating the sync channel is 
capable of processing three sync channel frames at a time. For the paging and traffic 
channels, each component is capable of processing four paging channel frames and four 
traffic channel frames at a time respectively. The receiver is capable of recovering any 
one of 64 individual channels. The receiver components are flexible enough to allow ease 
of reconfiguring to completely decode as many channels as needed. Table 16 illustrates 
the amount of data processed by each component at one time. Each column lists the 
component name and the rows are separated by channel type (pilot, sync, paging, traffic) 


and indicate the amount of data entering and leaving each component from each channel. 


ie 


COMPONENT 
CHANNEL 
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Sync channel 
Paging channel 
Traffic channel 
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Sync channel 
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S(n) -- multiplexed orthogonal baseband signal 


Table 16. Receiver data flow. 


E. RECEIVER COMPONENT DESCRIPTIONS 


The software components belonging to the receiver block diagram from Figure 29 


will now be described. Diagrams showing the flow of data into and out of a component 
are also shown. These diagrams follow the same convention used to describe a 
component in Chapter IV, Figure 19. All components are designed in a similar fashion. 
First, data entering a component is copied by the process_data method and stored in a 
buffer. The process_data method then processes the data by calling one or more 
processing methods. After the data has been processed, the process_data method copies 
the data into a buffer and then sends the data to the next component by calling the 
send_data method. Each component assumes a naming convention with the suffix title 
IS95B to distinguish it as a component designed for an IS95B system. This naming 
service is used mainly for identification and organization purposes and does not prevent 


the use of the components in other waveforms. 
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1. Quadrature Despreader 


Component Name: Quadrature_despreader_IS95B 


Port descriptions: This component has one uses and one provides port. Uses port 


is of type real float and provides port is of type complexFloat. 


Function: This component performs despreading of independent in phase and 
quadrature channel data. The same two short PN sequences used to spread data in the 
transmitter are used to despread the data in the receiver. The data entering this component 
normally comes from a decimator or digital filter component. The digital filter filters the 
incoming signal from the RF hardware to baseband. The decimator reduces the sampling 
frequency of the incoming signal [2]. The incoming data is first copied by the 
process_data method. The process_data method then processes the data by calling the 
following processing methods:  Initialise_ShortPNI,  Initialise_ShortPNQ, and 
DeSpread_data. Once the data is processed, the process_data method calls the send_data 
method to send the processed data to the next component. Functional description of this 
component is illustrated in Figure 30. The tasks of the processing methods used in this 


component are described in Table 17. 


Processing method Provides port Uses por 
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Digital filter/Decimator 








Process_data Method 














( euter( In-phase baseband data 


Quadrature baseband data 


Initialise_ShortPNI DeSpread_data DeSpread_data Initialise_ ShortPNQ 



















Walsh_Correlator_IS95B 





Figure 30. Quadrature_despreader_IS95B. 





PROCESSING METHOD 


TASK 





Initialise_ShortPNI 


This method initializes short quadrature PN 


Initialise_ShortPNQ 


This method initializes short in-phase PN 
sequence generator and creates in-phase PN 
sequence values for despreading channel data 


sequence generator and creates quadrature PN 
sequence values for despreading channel data 








DeSpread_data 





This method independently despreads channel 
data with in-phase and quadrature PN 
sequences 











Table 17. | Quadrature_despreader_IS95B processing methods tasks. 
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2. Walsh Correlator 
Component Name: Walsh_Correlator_IS95B 


Port descriptions: This component has three uses and one provides port. All ports 


are of type realFloat. 


Function: This component performs correlation of incoming signal with one of 
64 Walsh sequences to extract signal from any of 64 possible channels as described in 
Chapter III. For the receiver, only one channel recovered at any time: pilot, sync, 
assigned paging, or assigned traffic channel. Channel assignment for recovery is 
predetermined by a parameter passed to this component. The Walsh Correlator 
component extracts the desired channel data and sends the data to the corresponding 
channel normalizer (sync, paging, or traffic) by using one of three possible uses ports. 
The incoming data is first copied by the process_data method. The process_data method 
then processes the data by calling the following processing methods: Walsh_selection, 
Extract_SyncChannel, and Extract_PGorTrafficChannel. Once the data is processed, the 
process_data method calls the send_data method to send the processed data to the next 
component. Functional description of this component is illustrated in Figure 31. The tasks 


of the processing methods used in this component are described in Table 18. 
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| Quadrature_deSpreader_IS95B 








Process data Method 
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Extract_SyncChannel Extract_PGorTrafficChannel 
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Figure 31. Walsh_Correlator_IS95B 





PROCESSING METHOD 


TASK 





Walsh_ selection 


This method selects desired Walsh sequence 
from look up table. The Walsh sequences are 
used for correlation calculation with incoming 
data to extract any one of 64 possible channels 





Extract_SyncChannel 


This method is responsible for extracting sync 
channel from incoming data stream by 
performing correlation calculation described in 
Chapter III 








Extract_PGorTrafficChannel 





This method is responsible for extracting 
paging or traffic channel from incoming data 
stream by performing correlation calculation 
described in Chapter II 





Table 18. | Walsh_Correlator_IS95B processing methods tasks. 
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The next section describes the components for demodulating the different types of 
channels in the following order: sync channel, paging channel, and traffic channel. 
3. Sync Channel Normalizer 


Component Name: Syncch_Normalizer_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: The purpose of this component is to normalize the decision statistics 
out of the Walsh Correlator component to values that may be used as soft decision inputs 
into the sync channel decoder component. This component replaces a threshold detector 
that only provides statistics for hard decision decoders. The data is normalized so that the 
range of samples lie somewhere around -1 and +1. For example, if the incoming data 
samples are 3.3, 3.11, -3.12, -2.97, the samples are normalized to 1.3, 1.11, -1.12, -0.97. 
The incoming data is first copied by the process_data method. The process_data method 
then processes the data by calling the following processing method: Normalize_data. 
Once the data is processed, the process_data method calls the send_data method to send 
the processed data to the next component. Functional description of this component is 
illustrated in Figure 32. The task of the processing method used in this component is 


described in Table 19. 
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Walsh_Correlator_IS95B 








Process_data Method 


( euter(_) Normalize_data 

















Syncch_deinterleaver_IS95B 


Figure 32. Syncch_Normalizer_IS95B. 

















PROCESSING METHOD TASK 
Normalize_data This method normalizes incoming samples 
to a value somewhere around -1 or +1. 


Table 19. © Syncch_Normalizer_IS95B processing method task. 


4. Sync Channel Deinterleaver 


Component Name: Syncch_deinterleaver_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: This component deinterleaves sync channel data in blocks of 128 
symbols as described in Chapter HI. The incoming data is first copied by the 
process_data method. The process_data method then processes the data by calling the 


following processing method: Deinterleave_SyncChannel. Once the data is processed, the 
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process_data method calls the send_data method to send the processed data to the next 
component. Functional description of this component is illustrated in Figure 33. The task 


of the processing method used in this component is described in Table 20. 


Syncch_Normalizer_IS95B 














Process_data Method 


Deinterleave_SyncChannel 


















Symbol_removal_IS95B 





Figure 33. Syncch_deinterteleaver_IS95B. 











PROCESSING METHOD TASK 

Deinterleave_SyncChannel This method deinterleaves sync channel 
data in blocks of 128 symbols as described 
in Chapter III 








Table 20. Syncch_deinterleaver_IS95B processing method task. 


5. Symbol Removal 
Component Name: Symbol_removal_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 
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Function: This component removes repeated sync channel data changing data 
rate from 4.8 ks/s to 2.4 ks/s. The incoming data is first copied by the process_data 
method. The process_data method then processes the data by calling the following 
processing method: Symbol_removal. Once the data is processed, the process_data 
method calls the send_data method to send the processed data to the next component. 
Functional description of this component is illustrated in Figure 34. The task of the 


processing method used in this component is described in Table 21. 


Syncch_deinterleaver_IS95B 


Process_data Method 


( sutter(_) Symbol_removal 
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Figure 34. Symbol_removal_IS95B. 











PROCESSING METHOD TASK 
Symbol_removal This method removes symbols from sync 
channel 








Table 21. © Symbol_removal_IS95B processing method task. 
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6. Sync Channel Decoder 
Component Name: Syncch_decoder_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: This component decodes sync channel data to produce information bits 
while correcting most bit errors. A truncated Viterbi decoder that uses five kilobytes of 
memory is used for decoding the sync channel. This component was implemented using a 
similar algorithm from the IT++ communications library [21]. The five kilobytes of 
memory is the default value used by the IT++ communications library. From this 
component, the decoded bits would go to a higher layer data processing application for 
translation into meaningful data. This component also acts as a sink for sync channel 
data. No send_data method is needed in this component. The incoming data is first 
copied by the process_data method. The process_data method then processes the data by 
calling the following processing method: Decode_SyncChannel. Functional description 
of this component is illustrated in Figure 35. The task of the processing method used in 


this component is described in Table 22. 





Symbol_removal_IS95B | 








Process_data Method 















Decode_SyncChannel 


Sync channel bits 

















Figure 35. Syncch_decoder_IS95B. 
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PROCESSING METHOD 


TASK 








Decode_SyncChannel 





This method decodes sync channel using a 
Viterbi decoder described in Chapter III 





Table 22. Syncch_decoder_IS95B processing method task. 


7: Paging Channel Normalizer 


Component Name: Pagingch_Normalizer_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: The purpose of this component is to normalize the decision statistics out 


of the Walsh Correlator component to values that may be used as soft decision inputs into 


the paging channel decoder component. This component replaces a threshold detector 


that only provides statistics for hard decision decoders. The data is normalized so that the 


range of samples lie somewhere around -1 and +1. The incoming data is first copied by 


the process_data method. The process_data method then processes the data by calling 


the following processing method: Normalize_data. Once the data is processed, the 


process_data method calls the send_data method to send the processed data to the next 


component. Functional description of this component is illustrated in Figure 36. The task 


of the processing method used in this component is described in Table 23. 
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Figure 36. Pagingch_Normalizer_IS95B. 





PROCESSING METHOD TASK 








Normalize_data This method normalizes incoming samples 
to a value somewhere around -1 or +1. 








Table 23. Pagingch_Normalizer_IS95B processing method task. 


8. Paging Channel Descrambler 


Component Name: Pagingch_descrambler_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: This component descrambles channel symbols using unique long PN 
sequence as described in Chapter HI. The initial state of the PN code generators is 
initially determined by a value obtained as a parameter within this component. The 
encoder state is then continuously updated and stored in memory. The 


Pagingch_descrambler_IS95B component retrieves the current state of the generator from 
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memory whenever the generator is initialized. The incoming data is first copied by the 


process_data method. The process_data method then processes the data by calling the 


following processing methods: Initialize_GEN, and Descramble_Pagingdata. Once the 


data is processed, the process_data method calls the send_data method to send the 


processed data to the next component. Functional description of this component is 


illustrated in Figure 37. The tasks of the processing methods used in this component are 


described in Table 24. 
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Initialize_GEN 

















Figure 37. 
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Pagingch_descrambler_IS95B. 





PROCESSING METHOD 


TASK 





Initialize _ GEN 


This method initializes the long code PN 
sequence generator and creates long code 
PN sequence values for descrambling 
paging channel data 








Descramble_Pagingdata 





This method descrambles paging channel 
by multiplying long code PN sequence 
with paging channel data 





Table 24. 
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Pagingch_descrambler_IS95B processing methods tasks. 





9. Paging Channel Deinterleaver 


Component Name: Pagingch_deinterleaver_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: This component deinterleaves paging channel data in blocks of 384 
symbols as described in Chapter HI. The incoming data is first copied by the 
process_data method. The process_data method then processes the data by calling the 
following processing method: Deinterleave_PagingChannel. Once the data is processed, 
the process_data method calls the send_data method to send the processed data to the 
next component. Functional description of this component is illustrated in Figure 38. 


The task of the processing method used in this component is described in Table 25. 
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Figure 38. Pagingch_deinterleaver_IS95B. 
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PROCESSING METHOD TASK 

Deinterleave_PagingChannel This method deinterleaves paging channel 
data in blocks of 384 symbols as described 
in Chapter III 





Table 25. Pagingch_deinterleaver_IS95B processing method task. 


10. Paging Channel Decoder 
Component Name: Paging ch_decoder_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: This component decodes paging channel data to produce information 
bits while correcting most bit errors. A truncated Viterbi decoder that uses five kilobytes 
of memory is used for decoding the sync channel. This component was implemented 
using a similar algorithm from the IT++ communications library [21]. The five kilobytes 
of memory is the default value used by the IT++ communications library. From this 
component, the decoded bits would go to a higher layer data processing application for 
translation into meaningful data. This component also acts as a sink for paging channel 
data. No send_data method is needed in this component. The incoming data is first 
copied by the process_data method. The process_data method then processes the data by 
calling the following processing method: Decode_PagingChannel. Functional description 
of this component is illustrated in Figure 39. The task of the processing method used in 


this component is described in Table 26. 
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Figure 39. 


Pagingch_decoder_IS95B. 





PROCESSING METHOD 


TASK 








Decode_PagingChannel 


This method decodes paging channel using 
a Viterbi decoder described in Chapter III 





Table 26. Pagingch_decoder_IS95B processing method task. 


11. Traffic Channel Normalizer 


Component Name: Trafficch_Normalizer_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: The purpose of this component is to normalize the decision statistics out 


of the Walsh Correlator component to values that may be used as soft decision inputs into 


the traffic channel decoder component. This component replaces a threshold detector 


that only provides statistics for hard decision decoders. The data is normalized so that the 


range of samples lie somewhere around -1 and +1. The incoming data is first copied by 


the process_data method. The process_data method then processes the data by calling 


the following processing method: Normalize_data. Once the data is processed, the 


process_data method calls the send_data method to send the processed data to the next 
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component. Functional description of this component is illustrated in Figure 40. The task 


of the processing method used in this component is described in Table 27. 
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Figure 40. Trafficch_Normalizer_IS95B. 





PROCESSING METHOD TASK 








Normalize_data This method normalizes incoming samples 
to a value somewhere around -1 or +1. 
Table 27. | Trafficch_Normalizer_IS95B processing method task. 





12. ‘Traffic Channel Descrambler 
Component Name: Trafficch_descrambler_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


89 





Function: This component descrambles traffic channel symbols using unique long 
PN sequence as described in Chapter III. The initial state of the PN code generators is 
initially determined by a value obtained as a parameter within this component. The 
encoder state is then continuously updated and stored in memory. The 
Trafficch_descrambler_IS95B component retrieves the current state of the generator from 
memory whenever the generator is initialized. The incoming data is first copied by the 
process_data method. The process_data method then processes the data by calling the 
following processing methods: Initialize_GEN, and Descramble_Trafficdata. Once the 
data is processed, the process_data method calls the send_data method to send the 
processed data to the next component. Functional description of this component is 
illustrated in Figure 41. The tasks of the processing methods used in this component are 


described in Table 28. 
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Figure 41. Trafficch_descrambler_IS95B. 
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PROCESSING METHOD 


TASK 





Initialize _ GEN 


This method initializes the long code PN 
sequence generator and creates long code 
PN sequence values for descrambling 
traffic channel data 








Descramble_Trafficdata 





This method descrambles traffic channel by 
multiplying long code PN sequence with 
traffic channel data 





Table 28. Trafficch_descrambler_IS95B processing methods tasks. 


13. Traffic Channel Deinterleaver 


Component Name: Trafficch_deinterleaver_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: This component deinterleaves traffic channel data in blocks of 384 


symbols as described in Chapter II[. The incoming data is first copied by the 


process_data method. The process_data method then processes the data by calling the 


following processing method: Deinterleave_TrafficChannel. Once the data is processed, 


the process_data method calls the send_data method to send the processed data to the 


next component. Functional description of this component is illustrated in 0 The task of 


the processing method used in this component is described in Table 29. 
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Figure 42. Trafficch_deinterleaver_IS95B. 











PROCESSING METHOD TASK 

Deinterleave_TrafficChannel This method deinterleaves traffic channel 
data in blocks of 384 symbols as described 
in Chapter III 








Table 29. ‘Trafficch_deinterleaver_IS95B processing method task. 


14. Traffic Channel Decoder 
Component Name: Trafficch_decoder_IS95B 


Port descriptions: This component has one uses and one provides port. Both are of 


type realFloat. 


Function: This component decodes traffic channel data to produce information 
bits while correcting most bit errors. A Viterbi decoder inserts bits into the traffic channel 


to increase the data rate entering the Viterbi decoder from 19.2 ks/s to 28.8 ks/s. These 
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bits are known as dummy bits because they do not have an effect on the Viterbi algorithm 
used to decode the traffic channel. The Viterbi decoder knows the puncturing pattern 
used in the transmitter and the Viterbi decoder inserts two dummy bits in two out of 
every six positions of the incoming traffic channel data stream. The incoming data is first 
copied by the process_data method. The process_data method then processes the data by 
calling the following processing method: Decode_TrafficChannel. Once the data is 
processed, the process_data method calls the send_data method to send the processed 
data to the next component. Functional description of this component is illustrated in 
Figure 43. The task of the processing method used in this component is described in 


Table 30. 
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Figure 43. Trafficch_decoder_IS95B. 


PROCESSING METHOD TASK 








Decode_TrafficChannel This method decodes traffic channel using a 
Viterbi decoder described in Chapter III 








Table 30. Trafficch_decoder_IS95B processing method task. 
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15. Syndrome Detector 
Component Name: Syndrome_detector_IS95B 


Port descriptions: This component has one provides port of type realFloat. 


Function: This component checks traffic channel frames for bit errors as 
described in Chapter III]. The component calculates the syndrome vector by processing 
the incoming traffic channel data frames through a syndrome detector [18] described in 
Chapter III. This component also acts as a sink for traffic channel data. From here the 
decoded bits would go to a higher layer data processing application for translation into 
meaningful data. No send_data method is needed in this component. The incoming data 
is first copied by the process_data method. The process_data method then processes the 
data by calling the following processing method: Check_frame. Functional description of 
this component is illustrated in Figure 44. The task of the processing method used in this 


component is described in Table 31. 
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Figure 44. Syndrome_detector_IS95B 
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PROCESSING METHOD TASK 








Check_frame This method checks each traffic channel 
frame for bit errors by calculating the 
syndrome vector that results from passing 
each traffic channel frame through a 
syndrome detector described in Chapter HI 








Table 31. | Syndrome_detector_IS95B processing method task. 


F. ALGORITHM DEVELOPMENT 

Many algorithms were also derived for implementing the components in the 
receiver. These algorithms proved an invaluable source in effectively writing C++ code 
to implement the components’ specific functionalities. Furthermore, many of the receiver 
components were implemented by using similar concepts used in designing the 
transmitter components. For example, the deinterleaver component uses an algorithm that 
basically performs in a similar way to the interleaver. Another example is the quadrature 
despreader component that uses the same two PN sequences for despreading channel data 


that the quadrature spreader component uses to spread channel data. 


G. CODE DEVELOPMENT 

A few of the receiver components were implemented by using algorithms and 
C++ code from external references. These include the quadrature despreader, sync 
channel decoder, paging channel decoder, and traffic channel decoder. The quadrature 
spreader component uses an algorithm derived by converting Matlab code introduced by 
Harada and Prasad into C++ code [20]. The three decoder components were developed 


using similar C++ code found on the IT++ website [21]. 
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VII. TESTING, RESULTS, SYSTEM VERIFICATION, AND 
SYSTEM VALIDATION 


As INTRODUCTION 

In Chapter IV we described using the systems engineering “VEE” process model 
for designing our IS-95B transceiver system. So far we have traversed along the left side 
of the VEE model and we are at the point where we have described the design and 
development of the software components for the transceiver in Chapter V and Chapter 
VI. Following the design and development stage, the next step in our design process 1s 
the testing phase, followed by the design verification phase, and then finally the product 
validation phase. In the testing phase we aim to test all our components to ensure they 
are functioning correctly. Furthermore, once we test our individual components, we also 
want to integrate the components and conduct further testing to ensure that the 
components function together as a unit. Once integration testing is complete, we can 
conduct complete transceiver system testing to ensure our system is functioning correctly 
and satisfies all the requirements developed earlier in Chapter IV. In the verification 
phase, we verify our system by checking that our sub systems meet all of their assigned 
functional requirements. In the final stage, the product validation stage, we check our 
transceiver design to ensure that all the main system requirements have been met. In this 
chapter we will show how the IS-95B transceiver system was tested and the results from 
testing our transceiver design. We will also explain how the transceiver design was 


verified. The chapter concludes with validation of the entire transceiver design. 


B. TESTING METHODOLOGY 

When testing the components we should focus on using simple test data initially 
before testing the components with larger streams of data. For example, the convolutional 
encoder and traffic channel decoder components were first tested with a stream of four 
bits, say 1011, instead of using a frame of traffic channel data consisting of 280 bits. 
Once these two components were verified as functioning correctly, they were then tested 
with larger streams of data, such as a few frames of traffic channel data. This 


methodology allows simple testing and troubleshooting of a component or components if 
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errors occur. A test case for an IS-95B transceiver design was not available and hence 
another way of verifying that the components were functioning correctly was needed. 
Most of the components were tested and verified using analytical results and computer 
simulation results from Matlab generated code and IT++ sample programs. The data 
processed by the components was checked by using test files to store the processed data 
or by displaying the data on a computer or laptop monitor whenever feasible. The 


preferred method of checking the data involved using the test files. 


C. ADDITIONAL COMPONENTS USED FOR TESTING 

In order to test our transceiver we needed to develop three additional components, 
one for generating data, one for simulating a channel, and one for data type conversion. 
The component for generating data is called Gen_frame. The component for simulating a 
channel is called Channel, and the component for data type conversion is called 
short_to_float. 

1. Gen_frame 

The Gen_frame component was used in all testing phases of the transmitter design 
from individual component testing to complete transceiver testing. Gen_frame is 
designed with the flexibility to create test data of different sizes. Sometimes Gen_frame 
was used to generate a few bits for testing and sometimes it was used to generate data to 
represent sync, paging, and traffic channel frames for conducting a complete transceiver 
system test. 

2. Channel 

The Channel component was used as an interface for connecting our transmitter 
and receiver. The data entering the channel is assumed to be undisturbed by additive 
white Gaussian noise (AWGN) and hence we can transmit the baseband data out of our 
transmitter using the realShort interface, since this interface accommodates short data 
types, specifically integer values from -127 to 127. However, our receiver must account 
for AWGN so we need to represent the baseband samples entering our receiver using the 
realFloat interface. Using the realFloat interface allows our receiver to recover data 
consisting of float data samples (real numbers). The Channel component converts in 


phase and quadrature baseband samples out of the transmitter represented by CORBA 
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short sequences into CORBA float sequences. CORBA sequences are similar to arrays 
and are specified by the type of data they can carry, such as float and short. The Channel 
component outputs the in phase and quadrature samples to the first receiver component. 
Our transceiver design did not involve the addition of any AWGN to our transmitter 
generated waveform but in future designs the Channel component may be useful for 
adding an algorithm for generating AWGN. 

33 Short_to_float 

The short_to_float component acts as an interface for converting the data 
generated by a single or a group of transmitter components into data that can be 
processed by a single or group of receiver components. As mentioned above for the 
Channel component, a method was needed to convert data represented by CORBA short 
sequences to CORBA float sequences. The short_to_float component performs this 
translation of data. This component only accepts and outputs a single stream of data 
(real), unlike the Channel component that accepts and outputs in phase and quadrature 


data. 


D. TESTING PROCEDURE 

A formal set of procedures for testing our transceiver design was necessary. 
Figure 45 illustrates a sequential testing procedure developed for the IS-95B transceiver 
design. The testing procedures developed in this transceiver design are similar to the 


testing procedures used by Low from reference [3]. 
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Test transmitter component 


Test associated receiver component against 
transmitter component 


Integrate and test transmitter and receiver 
components 


Test complete transceiver design 


Figure 45. Testing procedure (After [3]). 


1. Single Component Testing 

First, the transmitter components were developed and tested by generating some 
data using the Gen_frame component and then sending the data through the transmitter 
component for processing. If the test results were satisfactory, then no further testing 
would be required. If the testing results were unsatisfactory, then troubleshooting would 
occur where the component design algorithms and programming code would be checked 
and modified as necessary to enable the component to function correctly. Later in this 
chapter we will discuss the analytical data used for testing. Figure 46 illustrates how 


individual transmitter components were tested. 


Generate test data Process data Verify results 


Gen_frame Transmitter Test File 
Component 


Figure 46. Example of single component testing. 
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2. Receiver Component Testing 

Once the transmitter components were tested successfully, the corresponding 
receiver components were developed and tested using the data output from the transmitter 
component. If the receiver component output matched the transmitter component input, 
then no further testing is necessary. If the receiver component output did not match, then 
troubleshooting would occur where the component design algorithms and programming 
code would be checked and modified as necessary to enable the receiver component to 
function correctly. Figure 47 illustrates the procedure for testing comparable transmitter 


and receiver components. 


Generate test data Process data Convert data Process data 


Gen_frames Transmitter Short_to_float Receiver 
Component Component 
Compare 
Test File data Test File 


Store data Store data 














Figure 47. Example of Transmitter/Receiver testing. 


3. Component Integration 

Once a group of transmitter and corresponding receiver components were 
successfully tested, the next step of tests involved integration of components where a 
group of transmitter components were tested with a group of corresponding receiver 
components. Figure 48 illustrates this procedure. It was important not to test too many 
components at one time because if errors were found, the troubleshooting process would 
become more difficult. Hence we started with just a small group of two transmitter and 
receiver components and then incremented by one transmitter and one receiver 


component each time. 
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Generate test data Process data Process data Convert data 


Gen_frames Transmitter Transmitter short_to_ float 
Component 1 Component 2 


Process data Process data 
: : Receiver Receiver 
Test File Test File 
Component 2 Component 1 
Store data Store data 





















Figure 48. Example of Integration testing. 


4. Complete System Test 

Once the integration tests were accepted as successful, the final testing step 
involved a complete transceiver test with all transmitter and receiver components. This 
step also involved using several files to keep track of input and output data from several 
of the transceiver components. To verify the results, the files were checked and compared 
to ensure the data matched. Specifically, the files were used to store the data from the 
different types of channels generated in the transmitter (pilot, sync, paging, and traffic) 
and also to store the data demodulated by the receiver for the different channels. The goal 
here was to verify that the channel data generated and modulated by the transmitter was 
successfully demodulated by the receiver. Figure 49 illustrates the testing procedure for 


the transceiver. 
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Generate test data Process data Convert data Process data 


Test File Test File 


Store data Store data 











Figure 49. Example of complete transceiver testing. 


E. PROCESSING SPEED 

One of the requirements for the transceiver is to process data at a maximum rate 
of 1.2288 samples per second equivalent to the data rate out of the transceiver and into 
the receiver of 1.2288 Mc/s. The transceiver design uses a general purpose processor, 
specifically an Intel Centrino duo processor with a clock rate of 1.66 GHz. For the 
transceiver design, we can make some calculations to determine if our general purpose 
processor is capable of processing data at a high enough rate so that if we were using the 
transceiver in real time, then our design would be capable of processing data at the IS- 
95B data rate. Recall earlier that the main purpose of our transmitter is to create an IS- 
95B signal for the receiver to recover and demodulate. Hence, we are more interested in 
checking the performance of our receiver, since the receiver design is a more practical 
one for recovering an IS-95B signal from a base station transmitter compared to our 
transmitter design for transmitting IS-95B signals. We will, however, still check the 
performance of the transmitter design. Since the transceiver design uses a general 
purpose processor, we can calculate how long it takes to process data in the Walsh 
Modulator component in the transmitter and Walsh Correlator component in the receiver, 
since these components are responsible for processing data at a rate equivalent tol.2288 
Mc/s. The following calculations were recorded for the afore-mentioned components 


using a timer class from reference [22]. 


103 


1. Walsh Modulator 
For this component we want to calculate how long it takes to spread incoming 


data, which in turn increases the data rate to 1.2288 Mc/s per channel. 
Number of data samples into component: 3456 
Number of data samples out of component: 393216 
Time to process samples: 0.0011805 seconds 


Processing rate: peaemaee = 33,307,275 samples 
0011805 ecu 


The above calculation suggests that the general purpose processor is more than 
capable of processing data equivalent to the IS-95B data rate of 1.2288 Mc/s. In reality, 
the transmitter would need some kind of buffer in the hardware section to limit the data 
rate out of the transmitter. 

2. Walsh Correlator 

For this component we want to calculate how long it takes to perform the 
necessary correlation operation to extract data a single channel from the incoming signal. 


Hence, we are checking how long it takes to process the incoming data samples. 
Number of data samples into component: 98304 
Number of data samples out of component: dependent on type of channel 
Time to process samples: 0.002164 seconds 


98304 ~ 45,426,987 samples 
.002164 second 





The above calculation also suggests that the general purpose processor more than 
capable of processing data equivalent to the IS-95B data rate of 1.2288 Mc/s. Hence, we 
can assume that the receiver design can process data at a maximum rate equivalent to the 


IS-95B maximum data rate of 1.2288 Mc/s. 


F. VERIFICATION OF TEST RESULTS 
Analytical calculations, Matlab programs, and IT++ sample programs were used 


to verify the functionality of some of the transceiver components. Analytical calculations 
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were conducted for all the transmitter components and for the Walsh Correlator 
component belonging to the receiver. Matlab programs were used to verify the 
functionality of Quadrature Spreader and Quadrature Despreader components by 
checking that the PN sequences generated were accurate. I[++ sample programs were 
used to verify results of data processed by convolutional encoder component and data 
processed by all three decoders in the receiver. Appendix B lists some of the methods 


used for verification purposes and includes samples of analytical results. 


G. TESTING SUMMARY 

The testing procedures used in this design provide an efficient way of producing 
the desired end result of a fully functioning transceiver. Sometimes, the tests did not 
produce the desired results because some of the components did not function correctly, 
but tedious troubleshooting and making of appropriate changes to the software algorithms 
produced the desired results. Eventually, the transceiver design underwent testing by 
generating continuous streams of test data and sending the data through the transceiver. 
The receiver was able to successfully recover the data generated and modulated by the 
transmitter. Appendix C contains a script that shows the results from testing the complete 
transceiver design. Before proceeding to the next section in this chapter, we need to state 
some additional requirements observed from testing that would benefit future designs and 
implementation of our current transceiver design. 

i Be PN Sequence Generators 

The two PN sequence generators used for creating PN sequences for quadrature 
spreading and despreading, and the PN sequence generator used for creating the PN 
sequence for scrambling and descrambling use locally generated parameters for 
initialization. There is a need to incorporate passing parameters that initialize the 
generators with the correct beginning state, so that the generators create the correct PN 
sequences for quadrature spreading and scrambling data in the transmitter, and quadrature 
despreading and descrambling data in the receiver. Accomplishing this task involves 
decoding incoming messages at a higher layer and then passing the appropriate 
parameters to the components. These higher layer applications were beyond the scope of 


this thesis and are recommended for future work. 
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The next step in our systems engineering process is the design verification phase. 
Here, we need to ensure that our sub systems have satisfactorily met all of their assigned 


design requirements. 


H. DESIGN VERIFICATION 

We will now check if our transmitter and receiver have met all their functional 
requirements using information from Table 4 in Chapter IV. 

1. Transmitter Requirements Verification 

a. Requirement: Simulate the forward link channel of IS-95B system with 
transmission of data from base station to mobile receiver. This requirement is met since 
transmitter is capable of generating an IS-95B like baseband signal for 14.4 kb/s 


operations. 


b. Requirement: Transmit up to 64 orthogonal code division multiplexed 
signals. This requirement is met since transmitter components are built with the 
flexibility to add up 64 to channels by simply modifying the header file, IS- 
95B_TX_library.h and also modifying some of the processing methods. 


C: Requirement: Simulate four distinct channels: pilot, sync, paging, and 
traffic channels. The transmitter meets this requirement since it can create four distinct 
channels that resemble the four types of channels normally created by an IS-95B base 


station transmitter. 


d. Requirement: Perform data signal processing using baseband data. The 
transmitter performs data processing using locally generated random data that is not 


subject to any carrier modulation. 


Gi Requirement: Process data at a minimum rate of 1.2288 Mc/s. The 
calculations conducted for checking the processing speed of the transmitter suggests that 


this requirement has been met. 


Es Requirement: Process data in frames of 20 ms in length. All transmitter 


components were designed to handle data consisting of frames that are 20 ms in length. 
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g. Requirement: Build system with reconfigurable software components. All 
transmitter components are built with the flexibility of easily being reconfigured for other 
applications, such as changing the mode of operations of the current IS-95B system, or 
for use in other waveforms. The components are built with the ability for a radio designer 
to simply modify or add more processing methods to achieve a desired capability. For 
example, the convolutional encoder component is designed with a constraint length of 
nine, but can be modified to perform encoding of data with other constraint lengths. 
Another example is the Walsh Modulator component created with a look up table 
consisting of 64 unique Walsh sequences. If another Walsh sequence set, such as a 
smaller group of eight Walsh sequences is needed, the radio designer can add a new 


method with the eight Walsh sequences and re-use this component. 


h. Requirement: Build system with reusable software components. The 
transmitter components are reusable with other waveforms that require similar 
components. The components are reusable because they are stored as part of an available 
library of components when creating waveforms using OWD. A radio designer can use 
these components for other waveforms and modify them as necessary to perform a 
specific function similar to the components’ specific function. For example, the 
Quadrature Spreader component creates two PN sequences with a length of 32768 bits 
each. A radio designer can reuse this component to create other PN sequences of the 
same length but with different characteristic polynomials. 

Zz Receiver Requirements Verification 

a. Requirement: Build receiver to recover an IS-95B communication 
waveform transmitted by a base station. The receiver is capable of recovering IS-95B 


signal modulated and transmitted by transmitter. 


b. Requirement: Perform data signal processing using baseband data. The 
receiver was designed to perform data processing on baseband data only. This 
requirement assumes that a suitable hardware interface will supply the receiver with the 


baseband data. 
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C: Requirement: Extract pilot, sync, paging, and traffic channel message 
data from orthogonal code division multiplexed signal. The receiver was tested 


successfully with the ability to extract the four different channel types. 


d. Requirement: Process data at a minimum rate of 1.2288 Mc/s. The 
calculations conducted for measuring processing speed in the receiver suggest that this 
requirement is met since the receiver has processing speed that exceeds data rate of 


1.2288 Mc/s. 


oe Requirement: Process data in frames of 20 ms in length. All receiver 


components were designed to handle data consisting of frames that are 20 ms in length. 


f. Requirement: Build the system with reconfigurable software components. 
The receiver components were also built with the flexibility of easily being reconfigured 
for other applications, such as changing the mode of operations of the current IS-95B 
system, or for use in other waveforms. The receiver is currently built to recover only one 
channel at any time, but it is possible to design the receiver to recover multiple channels, 
specifically traffic channels, at the same time, thus enabling even better performance by 
allowing for a possible increase in data rate. This design consideration was not explored 


and only stated as a reference for future designs. 


g. Requirement: Build the system with reusable software components. The 
receiver components are reusable with other waveforms that require similar components. 
The components are reusable because they are stored as part of an available library of 
components when creating waveforms using OWD. A radio designer can use these 
components for other waveforms and modify them as necessary to perform a specific 


function similar to the components’ specific function. 


I. TRANSCEIVER VALIDATION 

Upon verification that the sub systems (transmitter and receiver) have met all their 
functional requirements, the final verification step involves product validation by 
checking that the transceiver system meets all of its main requirements. These main 


requirements were listed in Chapter IV. 
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a. Requirement: The system must be able to transmit and receive IS-95B 
signals. This requirement has been satisfactorily met since the transceiver design was 


tested successfully. 


b. Requirement: The system must have the capability to interface with the 
hardware portion of a radio transceiver. Although we have not tested our transceiver 
with hardware, our transceiver does have the capability to interface with hardware since 
the components were created using OSSIE and the OWD. The OSSIE framework 
currently enables waveforms to interact with the Universal Software Radio Peripheral 
(USRP) device. Thus, we can safely make the assumption that our transceiver design has 


the ability to interface with hardware. 


ef Requirement: The system must be built with software components that 
meet the requirements of the SCA. Our transceiver design was created using the OSSIE 
software architecture. Since OSSIE is based on specifications from the SCA, our design 


meets the above requirement. 


d. Requirement: The system must be built with as little complexity as possible 
to allow for ease of testing, data processing, and reconfiguration. Our transceiver design 
meets this requirement since the transceiver consists of very flexible and easy to use 
components. First, the transceiver components are built with the ability to allow users to 
perform testing at many different stages in the component itself, making the components 
very easy to troubleshoot. Second, data processing is performed on only a sample of data 
at any time, allowing users the benefits of easily keeping track of data. Furthermore, the 
components provide radio designers an easy way of modifying a component’s function 
by simply adding, removing, or modifying methods inside the component. In addition, 
each component is well documented to allow users to understand the algorithm used to 


implement the component’s specific function. 


J. RESULTS SUMMARY 
The IS-95B transceiver system has been designed using the VEE systems 
engineering process model and we have successfully been able to traverse through every 


step of the model from development of system requirements to product validation. The 
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IS-95B transmitter created provides a means to generate IS-95B baseband signals that 
resemble signals normally transmitted by an IS-95B base station and the IS95B receiver 
provides a means to recover and demodulate baseband signals that an IS-95B mobile 
receiver would normally recover and demodulate. The transceiver design was only 
created for single mode operations to allow for data processing at the IS-95B information 
data rate of 14.4 kb/s. Modifying the transceiver design for multi-mode operations was 
explored, but not implemented. To enable multi-mode operations, the transmitter would 
require modification of the CRC and convolutional encoder components to account for 
the difference in the frame size of the traffic channel at a different data rate. The receiver 
would also require modification of the traffic channel decoder and syndrome detector 
components to account for the change in the traffic channel frame size. The modification 
would involve adding additional methods to process the traffic channel data at a different 


data rate. 
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VII. CONCLUSIONS AND FUTURE CONSIDERATIONS 


A. SUMMARY 

The JTRS Joint Program Executive Office is currently developing SDRs for use 
by all branches of the military. Furthermore, the future of radio designs for military 
applications as well as some commercial applications is leaning towards the use of SDRs. 
The increasing popularity of using SDRs perhaps stems from the many advantages of 
software radios, some of which were mentioned in Chapter II. This thesis has 


demonstrated the use of a SDR design in implementing a wireless transceiver. 


The major goal of this thesis work involved building a communications 
transceiver using software radio techniques. The transceiver needed to perform the same 
functions as the physical layers of an IS-95B hardware-based system. This goal has been 
accomplished by translating the physical layer models of an IS-95B base station 
transmitter and corresponding mobile receiver into comparable software models where 
the functions normally performed by hardware components are now performed using 
software generated components. We have also met the task of building an IS-95B 
transceiver that complies with the SCA by using OSSIE. By using an architecture that 
complies with SCA specifications, we have shown that the SCA is a valid option among 
software architectures for implementing waveform designs. This thesis work has also 
enabled us to contribute to a growing library of software components that can be re-used 
by other waveform applications. A total of 23 software components have been built, eight 
for the transmitter design and 15 for the receiver design. The components provide a 
foundation for building a complete IS-95B transceiver and the components also provide a 
foundation for creating other CDMA communication waveforms besides an IS-95B 
communications waveform. Furthermore, this thesis work provided a means of enhancing 
academic relationships between NPS students and students from the MPRG. Students at 
NPS continue to use the MPRG’s OSSIE platform to build communications waveforms 


and the research efforts conducted at NPS has helped the MPRG in making OSSIE better. 
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Overall, the thesis work completed was a beneficial learning experience. Over the 


course of conducting this thesis work, a few lessons have been learned and are worth 


listing. 


B. 


Learning to use new software can become a time consuming and tedious 
task. It is important to get as much help as possible from external sources, 
such as the software providers, textbooks, and personnel experienced in 
the use of the software. One of the experiences gained from this thesis 
work involved learning to use the Linux operating systems. We highly 
recommend becoming familiarized with the Linux operating system before 


using OSSIE and the OWD to build radio waveforms. 


When conducting research, we found it more beneficial to use a team 
approach in solving some problems. Groups of students focusing on the 
same problem provide more innovation than just one person focusing on 
the same problem. Remember to reach out for help whenever possible 
because some problems take much longer to solve when an individual 


attempts to tackle the problem, compared to a group of individuals. 


FUTURE CONSIDERATIONS 


The thesis work conducted has created a solid foundation for building a complete 


IS-95B radio transceiver. One of the major goals when developing SDRs is to perform 


modulation and demodulation of signals with the use of as little hardware as possible. As 


such, we recommend implementing as many of the hardware components as possible that 


were not implemented by software components in this transceiver design into software 


components. Some of these recommendations are listed below. 


Pulse shaping is often employed in an IS-95B base station transmitter 
signal to reduce inter-symbol interference at the receiver. We recommend 
that this function be performed in software and hence a software 
component for performing baseband pulse shaping may be developed. 
This pulse shaping would normally take place prior to carrier modulation 


in the transmitter and after carrier demodulation in the receiver [18]. 
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e Since the IS-95B transceiver design was implemented as a perfectly 
synchronized transceiver, components are needed to _ perform 
synchronization between the transmitter and receiver. We recommend 
developing software components for performing PN code acquisition and 
tracking. In addition, we recommend developing software components for 


determining frequency and phase synchronization. 


e The IS-95B transceiver design has the ability to interface with hardware. 
Therefore, we recommend implementing the transceiver components 
already built into a fully functional [S-95B radio transceiver. To do so, we 
also recommend the use of the USRP device as a hardware source for 
further testing of the transceiver design. In order to interface with 
appropriate hardware for transmitting and receiving the IS-95B signals, a 
few additional software components are required. These include 
interpolators, decimators, and digital filters. Many of these software 
components are already available as part of a repository on the OSSIE 


website [1]. 


e The IS-95B receiver design was not tested using a noisy channel or under 
the effects of a multi-path fading environment. We recommend making 
modifications in the IS-95B receiver to accommodate noisy channels and 


multi-path fading environments. 


e The transceiver design only operates in a single mode of operation to 
perform data processing at the IS-95B data rate of 14.4 kb/s. Modifying 


the transceiver design for multi-mode operations is also recommended. 


The recommendations listed above will help improve the overall IS-95B 
transceiver design as well as help facilitate research for improving the capabilities of 


SDRs. 
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APPENDIX A. WALSH SEQUENCES 
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Walsh sequences of order 64 (From [23]) 


Table 32 
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APPENDIX B. ANALYTICAL CALCULATIONS 


A. INTRODUCTION 

This appendix lists some sample analytical calculations used to verify the 
functionality of the transmitter components. In addition, some of the other methods used 
to verify the functionality of some of the components is discussed. 

1. CRC Analytical Calculation 


Let the information data u = 1001. This implies u(x) =1+4+ x° 
From Chapter III, the generator polynomial is g(x) =1+x° +x" +x'° 


For cyclic codes the code polynomial for a (n,k) cyclic encoder, v(x), can be found by 


the following calculations using reference [15]. 








n—k 
The equation gail Baye where a(x)= the quotient and b(x)= the 
8 (x) 8(x) 
remainder and v(x) = b(x) +x" “u(x) 
Hence 
x" u(x) Z xi + x yl eee ee 
g(x) 14x Seg :5,'° 1+x° 4 x7 4 x/6 


v(x) = 1x3 $2 toy 4 x? 4 x 4 x6 4 


v =10010100100010011001 where the first 16 bits are the parity bits 
and the last four bits are the information bits. 
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2. Convolutional Encoder Verification 
If input,u=1011 then U=1+D*+D?* and using the generator polynomials 
from Chapter II [15], 


Gl=1+4D1+4+ D2 + D3 + D5 + D7 + D8 
G2=1+ D2+ D3 + D4 D8 


V1 = UG! = 14+-D'+D°>+D°+D°+D°+D" and 
V2 = UG2 = 14+D'+D'+pD"%+pD" 

vl = 110101100101 

v2 = 100000011011 

v = 111000100010100101100111 


Since the sync channel and paging channel have no tail bits added, we only need 
to verify the first eight encoded bits from v since the last 16 bits resulted from encoding 


eight tail bits that would normally be added to a block of data entering the encoder. 
Hence v = 11100010 


For the traffic channel, the output is punctured every two out of three values inv. 


Hence the output v = 1100100110101011 


The convolutional encoder results were also verified using a sample test program 
from IT++ website [18]. The same input was used and the resulting output checked 
against the outputs from the convolutional encoder component. 

a Interleaver Verification 

To test the interleaver component, we create two input arrays, one for testing the 
sync channel interleaving process and one for testing the paging/traffic channel 
interleaving process. 

a. Sync Channel Interleaving 

The first array has a data size of 128 symbols and consists of integer 
values from 0 to 127. This array of integers is used to test the interleaving of the sync 
channel. Recall that each syne channel frame consisting of 128 symbols is interleaved 
using a bit reversal pattern. Table 33 and Table 34 show the data in the array prior to 


interleaving and the expected array contents after interleaving. 
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0 16 ae 48 64 80 96 112 
1 iy 33 49 65 81 97 113 
2 18 34 50 66 82 98 114 
3 19 35 51 67 83 eae 115 
4 20 36 o2 68 84 100 116 
5 21 37 53 69 85 101 117 
6 22 38 54 70 86 102 118 
7 23 39 5D 71 87 103 119 
8 24 40 56 72 88 104 120 
9 pes: 41 57 fie) 89 105 121 
10 26 42 58 74 90 106 122 
11 ra 43 59 oe) 91 107 123 
12 28 44 60 76 92 108 124 
13 29 45 61 a) 93 109 125 
14 30 46 62 78 94 110 126 
15 31 47 63 79 95 111 127 
Table 33. Sync channel array prior to Interleaving (From [15]). 
0 4 2 6 1 5 3 7 
64 68 66 70 65 69 67 71 
a2 36 34 38 33 37 a2 39 
96 100 98 102 oF 101 ae 103 
16 20 18 22 17 21 19 23 
80 84 82 86 81 85 83 87 
48 52 50 54 49 53 51 oD 
112 116 114 118 113 117 115 119 
8 12 10 14 9 13 11 15 
ae 76 74 78 73 vei 1 79 
40 44 42 46 41 45 43 47 
104 108 106 110 105 109 107 111 
24 28 26 30 25 29 pa | 31 
88 o2 90 94 89 23 91 95 
56 60 58 62 57 61 59 63 
120 124 122 126 121 125 123 127 
Table 34. Sync channel array contents after interleaving (From [15]). 
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b. Paging and Traffic Channel Interleaving 

The array used for testing the paging and traffic channel interleaving 
process consists of integer values from 1 to 384. The paging and traffic channels also use 
a bit reversal technique for interleaving as explained in Chapter II. Table 35 and Table 
36 show the data in the array prior to interleaving and the expected array contents after 


interleaving. 





25 | 49 | 73 | 97 | 121 | 145 | 169 | 193 | 217 | 241 | 265 | 289 | 313 | 337 | 361 





26 | 50 | 74 | 98 | 122 | 146 | 170 | 194 | 218 | 242 | 266 | 290 | 314 | 338 | 362 





27 | 51 | 75 | 99 | 123 | 147 | 171 | 195 | 219 | 243 | 267 | 291 | 315 | 339 | 363 





28 | 52 | 76 | 100 | 124 | 148 | 172 | 196 | 220 | 244 | 268 | 292 | 316 | 340 | 364 





29 | 53 | 77 | 101 | 125 | 149 | 173 | 197 | 221 | 245 | 269 | 293 | 317 | 341 | 365 





30 | 54 | 78 | 102 | 126 | 150 | 174 | 198 | 222 | 246 | 270 | 294 | 318 | 342 | 366 





31 | 55 | 79 | 103 | 127 | 151 | 175 | 199 | 223 | 247 | 271 | 295 | 319 | 343 | 367 





CO;N DI Ny BRIO }N]Re 


32 | 56 | 80 | 104 | 128 | 152 | 176 | 200 | 224 | 248 | 272 | 296 | 320 | 344 | 368 





\O 


33 | 57 | 81 | 105 | 129 | 153 | 177 | 201 | 225 | 249 | 273 | 297 | 321 | 345 | 369 
34 | 58 | 82 | 106 | 130 | 154 | 178 | 202 | 226 | 250 | 274 | 298 | 322 | 346 | 370 





30-99" 83) LOF 13d T5541 B79") 203 227: Qad 2 I5 299" 323 | 347) 3741 





36 | 60 | 84 | 107 | 132 | 156 | 180 | 204 | 228 | 252 | 276 | 300 | 324 | 348 | 372 





37 | 61 | 85 | 109 | 133 | 157 | 181 | 205 | 229 | 253 | 277 | 301 | 325 | 349 | 373 





38 | 62 | 86 | 110 | 134 | 158 | 182 | 206 | 230 | 254 | 278 | 302 | 326 | 350 | 374 





39 | 63 | 87 | 111 | 135 | 159 | 183 | 207 | 231 | 255 | 279 | 303 | 327 | 351 | 375 





40 | 64 | 88 | 112 | 136 | 160 | 184 | 208 | 232 | 256 | 280 | 304 | 328 | 352 | 376 
41 | 65 | 89 | 113 | 137 | 161 | 185 | 209 | 233 | 257 | 281 | 305 | 329 | 353 | 377 





42 | 66 | 90 | 114 | 138 | 162 | 186 | 210 | 234 | 258 | 282 | 306 | 330 | 354 | 378 
43 | 67 | 91 | 115 | 139 | 163 | 187 | 211 | 235 | 259 | 283 | 307 | 331 | 355 | 379 





Nl Rl Rel ele lel Rel Rel Re le le 
SIO] Oo}N] AN] Ny BRI] G |W] Re | oO 


44 | 68 | 92 | 116 | 140 | 164 | 188 | 212 | 236 | 260 | 284 | 308 | 332 | 356 | 380 





N 
— 


45 | 69 | 93 | 117 | 141 | 165 | 189 | 213 | 237 | 261 | 285 | 309 | 333 | 357 | 381 





N 
N 


46 | 70 | 94 | 118 | 142 | 166 | 190 | 214 | 238 | 262 | 286 | 310 | 334 | 358 | 382 





N 
1S) 


47 | 71 | 95 | 119 | 143 | 167 | 191 | 215 | 239 | 263 | 287 | 311 | 335 | 359 | 383 








) 
aN 















































48 | 72 | 96 | 120 | 144 | 168 | 192 | 216 | 240 | 264 | 288 | 312 | 336 | 360 | 384 





Table 35. Paging/Traffic channel array prior to Interleaving (From [15]). 
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81 | 89 
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Table 36. 
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Paging/Traffic channel array after Interleaving (From [15]). 


Symbol Repetition Verification 








384 


Analytical results are simple to generate. The input data is simply repeated for 


each bit. For example, input bit stream uv =1011, output bit stream v= 11001111. 


3: 


LongPN_Scrambler Calculation 


The long PN sequence generator has a period of 2**—1. The long PN generator 


creates PN sequence values according to the current state of the long PN code [15]. For 


testing purposes we assign an arbitrary value as our starting reference for the long PN 


code generator and create a sequence equal in size to the incoming channel data. The 


state of the encoder is kept updated so that the incoming data that requires scrambling is 


continuously scrambled by a PN sequence that is continuously updated. Table 37 


illustrates the analytical results calculated and used to verify the functionality of the 
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LongPN scrambler component. The scrambling operation is a simple multiplication 


operation between PN sequence code bits and input bits. 




















Input data 10010011 
Input data in NRZ format -1 1 1-1 1 1-1-1 
Long PN sequence code values 1-l 1111-11 
Scrambled data output -l-l 1-11 11-1 





NRZ — non return to zero 


6. 


Table 37. | Long code scrambling calculation. 


Walsh Modulator Calculations 


The input data is a stream of bits and the output is a stream of bits spread by a 


factor of 64 for paging and traffic channels and a factor of 264 for the sync channel. The 


Walsh sequence values are modulated (multiplied) by the input data. 


a. Sync Channel Spreading 
Sync channel data input: vu =10, NRZ format u=—11 


Walsh function, H32, from look up table in NRZ format. 


{hp obhpaly 1, 1,-1,-1, 1, 1,-1,-1, 1, 1,-1,-1, 1, 1,-1,-1, 1, Lol, > 


1, 1, Lilly 1, Leh by 1, boa hye aly; 1, 1,-1,-1, 1, 1,-1,-1, 1, Leola l; 1, 1,-1,- 


1,1,1,-1,-1,1,1,-1,-1,1,1,-1,-1,1} [15] 


Sync cannel data output: 2*256=512 bits shown below 
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b. Traffic Channel Spreading 
Traffic channel data input: vu = 1011, NRZ format u= -1 1-1-1 


Walsh function, H8, from look up table in NRZ format. 





{1,1,1,1, 1, 1, 1, 1, 1, 1, 1, 1,1,1,1,1,1,1,1,1,-1,-1,-1,- 
Phe Si eh Cat eed Th Mek eek poh ae ark ST ee See eh I ee oe a 








1,-1,-1,-1,-1,-1,-1,-1,1,1,1,1} [15] 


Traffic channel data output: 4 * 64 = 256 bits shown below 









































































































































-1-1-1-111111111-1-1-1-1-1-1-1-111111111-1-1-1-1-1-1-1 
111111111-1-1-1-1-1-1-1-111111111-1-1-1-11111-1-1-1-1-1-1-1-111111111- 
1 PTAs PIV 1111-1 
1-1-11111111 sla fs a 11111111-1-1-1-1- 
1-1-1-11111111 fs 11111111-1-1-1- 
1-1-1-1-111111111 11111111-1-1-1-1] 

iP Quadrature Spreader Calculations 


Recall that the in phase and quadrature PN sequences generated by this 
component are 2%15 in length due to an additional zero inserted into the sequence as 
mentioned in Chapter III. To verify the PN sequence values created by the Quadrature 
Spreader component were accurate, we compared one period of the PN sequences 
generated against PN sequences generated by a Matlab program for creating PN 
sequences taken from reference [18]. Once the PN sequences were compared and verified 
as accurate, we could then check that the component would spread (modulate) the 
incoming data accurately. The calculation involves simple multiplication between the 
input data bits and PN sequence values. The input data rate is not actually increased so 


this component is just modulating the input data. 
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Input data 10010011 

Input data in NRZ format -l11-111-1-1 

In phase PN sequence values -l1-11-111-1 

In phase data output 11-1-1-l1-11 

Input data in NRZ format -lL11-111-1-1 

Quadrature PN sequence values -lL11-1-1-1-11 
Quadrature data output 1111-1-11-1 





Table 38. 


In phase and quadrature modulation calculation. 


8. Multiplex Channels Calculation 


This component adds all the in phase and quadrature channels to produce a single 


in phase and a single quadrature channel. The analytical results used to check the 


functionality of this component are illustrated below. 






































In phase pilot channel data 11-1-l11-11 
In phase sync channel data 1-l111-1-111 
In phase paging channel data 1-l1l11-l11 
In phase traffic channel data -l-l11-1-111 
Multiplexed in phase channel data -2 -2220224 
Quadrature pilot channel data 111-11-1-11 
Quadrature sync channel data 11-1-1-1-111 
Quadrature paging channel data 1-l11-11-11 
Quadrature traffic channel data -ll-l1-1111 
Multiplexed quadrature channel data 2220-4004 





Table 39. 


Multiplex channels calculation. 
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APPENDIX C. TESTING RESULTS 


A. INTRODUCTION 

This Appendix shows a script displaying the results from testing the IS-95B 
transceiver design. The script shows the flow of data from the transmitter to the receiver. 
First, the transmitter generates frames for simulating pilot, sync, paging, and traffic 
channel data. The data is then processed as it goes from one transmitter component to the 
next. Finally after the data leaves the last transmitter component, the data is received by 
the receiver. The data is then processed by the receiver components and the receiver 
displays the recovered data. Only one channel type (sync channel, paging channel, or 
traffic channel) can be recovered at any time as explained in Chapter VI. The script 
shows the recovery of data for each type of channel. The first script displays recovery of 
sync channel data. The second script shows recovery of paging channel data, and the last 


script shows the recovery of traffic channel data. 


B. SYNC CHANNEL 

This script shows the transmitter data flow followed by receiver data flow for 
recovering sync channel data. At the beginning of the script, the uncoded sync channel 
data bits are displayed and at the end of the script the recovered sync channel data bits are 
displayed. The script shows that the recovered data bits match the uncoded data bits. We 
also observe that the sync channel data that has been recovered suffers from a delay due 


to using a truncated Viterbi decoder. 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 


Welcome to IS95B transceiver demo! 
KK KK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKKKKK KKK 


Creating three sync channel frames, four paging channel frames, and 
four traffic channel frames for transmission 


sending data to CRC encoder now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering CRC component 
data received from Gen_frames, length: 1920 
Parity bits added to traffic channel frames 


sending data to convolutional encoder 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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uncoded paging channel bits: 
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encoding process complete 


sending data to symbol repetition component 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Symbol repetition component 


OES Or OuOrt 


QO) | 





CO Om 
POORER 


oooorrot 
Poqocnooo°oco 





OC OCR Ao Reet 
FS: vO. @7O; SC 


data received from conv encoder component, length: 
symbol insertion complete: sync channel data rate doubled 





sending data to Interleaver now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Interleaver component 


data received from symbol repetition, length: 


Interleaving Process completed 


sending data to Long PN Scrambler 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Long PN Scrambler component 


Frame data received from Interleaver, length: 





scrambling process completed 


sending data to Walsh Modulator component 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Walsh Modulator component 
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Frame data received from Long PN Scrambler component, length: 3456 
Walsh Modulation complete 


sending data to quadrature spreader now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering quadrature spreader component 
data received from Walsh modulator, length: 393216 
Quadrature spreading complete 


sending data to be multiplex_channels component now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 











KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering multiplex_channels component now 
data received from quadrature spreader, length: 393216 
Multiplexing complete 


sending data to receiver now via channel 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 











KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKK 


In Channel 


sending data to Receiver 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 


In Receiver Quadrature despreader component 
data received, length: 98304 
Quadrature despreading complete 


sending data to Walsh correlator now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


In Walsh Correlator component 

data received from quadrature despreader, length: 98304 

choose channel mode: (s=sync channel, p=paging channel, t=traffic 
channel) 

s 

Walsh correlation complete 


sending data to sync channel normalizer now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 








KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering sync channel normalizer now 
data received from Correlator, length: 384 
Normalization of data complete 


sending data to sync channel deinterleaver now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 











KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering sync channel deinterlaver 
data received from Normalizer, length: 384 
deinterleaving process completed 


sending data to symbol removal component now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 








KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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In symbol removal component 
data received from deinterleaver, length384 
symbol removal process completed 


sending data to sync channel decoder now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 








KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering sync channel decoder 
data received from symbol removal component, length: 192 


decoder initialised : 0 





decoded sync channel bits: [] 
decoded sync channel bits: [101111001101011000 0] 
decoded sync channel bits: [00101100011110001110101 


11103100101) 


C, PAGING CHANNEL 

This script shows the transmitter data flow followed by receiver data flow for 
recovering paging channel data. At the beginning of the script, the uncoded paging 
channel data bits are displayed and at the end of the script the recovered paging channel 
data bits are displayed. The script shows that the recovered data bits match the uncoded 
data bits. We also observe that the paging channel data that has been recovered suffers 


from a delay due to using a truncated Viterbi decoder. 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Welcome to IS95B transceiver demo! 
KK KK KKK KKK KKK KK KKK KKK KKK KKK KKK KK KKK KKKKKKHK 


Creating three sync channel frames, four paging channel frames, and 
four traffic channel frames for transmission 


sending channel data to CRC encoder now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering CRC component 
data received from Gen_frames, length: 1920 
Parity bits added to traffic channel frames 


sending data to convolutional encoder 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering convolutional encoder 
data received, length: 1984 


in conv encoder process function 
uncoded syne channel bits: [111000000011001000001 0 
0110310100 0] 
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001100121111100100100101000010101110121 
10011121001101101000010001100010110100 
0000101001111100001101201131230010010010 


010001111111100132303142323031423320121001001321121 


0101000001101201100001100i11~1) 


1000101100100011010100 


11000001211111001101101100110010310010 
111000010000011000011111100101010100 


uncoded paging channel bits: 


001000001100111000112011120120000000010 


0101111000101001010001101110100131110 


0010100000101201110001101i11 0) 


(Oo0110000700720720100001 


000110001101011011131230001123211313233113134d31d3100 


uncoded paging channel bits: 


110101000012010111100001110011313110000 
10010121100111001100011100001001010000 
000010110000011100000100101101101000 


01001000111312131213121313123120312031000 0) 


11010000000000011131110 


000011011000100001011201121201202700000021 


uncoded paging channel bits: 


1001011201100001000110000000110000110 
000100100000000100110120110013111131200d10 


0001111111011123000011110012001201310313110 


0101001001000101101200131000i1%) 
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uncoded traffic ch bits: [110111011 
0 101 QO) Both. DOP 0.000." (0) al. Oe se 1: 
0 010 02.0% 20: <0 ak 100001 0 
0 0 0 Te Or .O% Ls QUO? T4020 10031000 
0 01 00100010110031000 0 
0 001112120000000011 Td 0 
OPE. “O0' 02. Qed) Od. Ee Oo0° 010 100 
1000311000100 0 (Oi eg) 100 
0 On de A 

uncoded traffic ch bits: [110000001 
001000 010000000101 Ll 1 
001001 000010010110 0 
Lb Qy0: “D0 Oo 0-0) "OL 020.0. 0: LD) 20) ak ah. FOO. “Oe T 
0 L0? LL. 0260 de dd 20, <0} ak 0? <e O: ke. a 0 0 
TOA Oi. O O08 aks es 20> Odie" Dad hs. 20> Desh) 
Oo. Dh Oh dD De Ore0' Oe Te ds <Q) D000", 1, Or -O)-0 
T1iia111212320212000010001 1 1 0 
A Oy alis le de} 

encoding process complete 





sending data to symbol 


l repetition component 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Symbol repetition component 


data received from conv encoder component, 


symbol insertion comp] 
sending data to Inter] 





Leaver now 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Interleaver 


component 


data received from symbol repetition, lengt 
Interleaving Process completed 


sending data to Long PN Scrambler 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 





Entering Long PN Scrambler component 


Frame data received from Interleaver, lengt 
scrambling process completed 


sending data to Walsh Modulator component now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Walsh Modulator component 


Frame data received from Long PN Scrambler 
Walsh Modulation complete 


sending data to quadrature spreader now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKK KK 





Entering quadrature spreader component 


data received from Walsh modulator, length: 
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length: 3264 


h: 3456 


h: 3456 


component, 


393216 


lete: sync channel data rate doubled 


length: 


OG tl O- OO. FQ 











3456 





Fe -@ Re Ee AO@"'O 


PROrRPRROO 





CORPFRPRFREFROR 


OOO. OF ee Ae 


Quadrature spreading complete 


sending data to be multiplex_channels component now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering multiplex_channels component now 
data received from quadrature spreader, length: 393216 
Multiplexing complete 


sending data to receiver now via channel 
KKKKKKKK KKK KKK KKK KKK KKK KKK KKK KKK KKKKKKKKKK 











KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKK 


In Channel 


sending data to Receiver 
KKKKKKKKK KK KKK KKK KKK KKK KKK KKK KKK KKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKK 


In Receiver Quadrature despreader component 
data received, length: 98304 
Quadrature despreading complete 


sending data to Walsh correlator now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


In Walsh Correlator component 

data received from quadrature despreader, length: 98304 

choose channel mode: (s=sync channel, p=paging channel, t=traffic 
channel) 

p 

Walsh correlation complete 


sending data to paging channel normalizer now 
KKKKKKKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKKKKKKK 





data sent to quantizer 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering paging channel normalizer now 
data received from Correlator, length: 1536 





Normalization of data complete 


sending data to paging channel deinterleaver now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering paging channel descrambler 
data received from Normalizer, length: 1536 
descrambling process completed 


sending data to paging channel deinterleaver now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering paging channel deinterleaver 
data received from descrambler, length: 1536 
deinterleaving process completed 


sending data to paging channel decoder now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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sending data to decoder now 
KKKKKKKKKKKKKKKK KK KKK KKK KKK KK KKK KKK KKKKKKK 





Entering paging channel decoder 
data received from deinterleaver component, 


length: 


1536 


paging channel decoder initialised : 0 

decoded paging ch bits: [(01110110000110010001100 
1100111111003100100101000010101110110 
011100110110100001000110001011010000 
0010100111110000110101110010010010021 
00011311d312131d131200121 ‘03 

decoded paging ch bits: [11011101001001111101010 
0000110101100001100111000101100100021 
1010100110000011111100131013101310013100 
1010010111000010000011000011131110010 
101010000100000110011100011011101000 
000001001011110001010010 i143 

decoded paging ch bits: [(00011011101001111000101 
00000101011100011011100011000010010121 
01000010001100011010110111100013121311d1i21 
11111001103103121000010132011110000111001i1 
111000010010110011100110001110000100 
10100000000101100000111 0 0j 

decoded paging ch bits: [000010010110110100001001 
00011111111113130101000010100000000000 
111111000001101100010000101101110101 
0000001100101101120000170001T11000000011 
000011000010010000000010011010110011 
111001000011311311311031d1d131000 0) 

D. TRAFFIC CHANNEL 


This script shows the transmitter data flow followed by receiver data flow for 


recovering traffic channel data. At the beginning of the script, the uncoded traffic channel 


data bits are displayed and at the end of the script the recovered traffic channel data bits 


are displayed. The script shows that the recovered data bits match the uncoded data bits. 


After the data bits are recovered, the traffic channel data goes to the syndrome detector 


component where the traffic channel frames are checked for bit errors. The script shows 


that no errors occur by displaying a Boolean variable, 1, meaning no bit errors. 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Welcome to IS95B transceiver demo! 
KK KK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKKKKK KKK 


Creating three sync channel frames, 
four traffic channel frames for transmission 


sending channel data to CRC encoder now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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four paging channel frames, 


and 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 


Entering CRC component 


amy 


1920 


Parity bits added to traffic channel frames 


length: 
sending data to convolutional encoder 


Sa 


data received from Gen_frames 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAK KK 
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1101101312120011100120100112012001T0000010121 
00001100101011012120010123121120111232001200021 
100120312111100113120001010000010110010i121 
10121011031203121110100100000110110100110121 
11010120012001111111000010100011100100 
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000101000111101120111101011311312031131312000 


1101031203121103121000100011101011201131201200021 


0011 Oj 


110111100110110010010010 


011101101110011000110101100001010000 
11001203121310031201312120011131203123120000101201021 
11101111000011103123120312131230313123131120000112312010 
110121031213111310312010103131200313121311200120131313100 
10121011110120000010101000001110101313110 
0111011111001201101113100000011201000110 
1110010121031320103121011312031320000100010000010 


uncoded traffic ch bits: 
0001 1)j 


100100111111001000010111 


0000010111011100001100100111201001111 


uncoded traffic ch bits: 


010100111112031213113230312011310111200000000 
0101011000100101010000110110111132010121 


00110011110312011010311311000111200000110 
101110011000011001010000001010001010 
00010010100001101111101001013120010000 


010101100001110011000110112100100011021 


1100 1) 


I11110111111001010101111 


uncoded traffic ch bits: 


01110011000101101011012011312001314123a00021 


11010312100010110101312110010100110101120021 
11100010000111101312111312300000111200011021 
1011012100110011100000001101201000000121 
1010110000100100110120001011110000110 
010011111100100100001121200121120000011121 
0001100000000010000001001101200000110 


0100 0) 


repetition component 





encoding process complete 
sending data to symbol 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 


Entering Symbol repetition component 


as 
amy 





length: 3264 
sync channel data rate doubled 


data received from conv encoder component, 


symbol insertion complete: 





sending data to Interleaver now 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Interleaver component 
data received from symbol repetition, 


Interleaving Process completed 


Entering 


= 
am 





3456 


length: 


sending data to Long PN Scrambler 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering Long PN Scrambler component 


= 
py 





3456 


length: 


Frame data received from Interleaver, 
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scrambling process completed 


sending data to Walsh Modulator component now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Walsh Modulator component 
Frame data received from Long PN Scrambler component, length: 3456 
Walsh Modulation complete 


sending data to quadrature spreader now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering quadrature spreader component 
data received from Walsh modulator, length: 393216 
Quadrature spreading complete 


sending data to be multiplex_channels component now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 











KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering multiplex_channels component now 
data received from quadrature spreader, length: 393216 
Multiplexing complete 


sending data to receiver now via channel 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 











KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 


In Channel 


sending data to Receiver 
KKKKKKKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


In Receiver Quadrature despreader component 
data received, length: 98304 
Quadrature despreading complete 


sending data to Walsh correlator now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


In Walsh Correlator component 

data received from quadrature despreader, length: 98304 

choose channel mode: (s=sync channel, p=paging channel, t=traffic 
channel) 

1 

Walsh correlation complete 


sending data to traffic channel normalizer now 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 


Entering traffic channel normalizer now 
data received from Correlator, length: 1536 





Normalization of data complete 
sending data to traffic channel descrambler now 
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KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Entering traffic channel descrambler 


= 
amy 





1536 


length: 


data received from Normalizer, 


descrambling process completed 





sending data to traffic channel deinterleaver now 
KKKKKKKK KK KKK KKK KKK KKK KKK KK KKK KKK KKKKKKKKK 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


av 
length: 


1536 








Entering traffic channel deinterl 


ay 
mh 











data received from descrambler, 


deinterleaving process completed 


sending data to traffic channel decoder now 
KKKKKKKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKKKKKKK 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKK 


Entering traffic channel decoder 


=} 
py 





1536 


length: 





data received from deinterleaver, 


111011101011101000110010 


1101103121001110010100110100100000101121 
00001100101011012120010121120111232001200021 


decoded traffic ch bits: 


1001203121111001131230001010000010110010i121 
1012101103120312111010010000011011010011021 
1101031200121001111111000010100011100100 
000101000111101101111010313112011312312000 


11010312031211012100010001110101120131201200021 


0011 Oj 


I10111100110110010010010 


011101101110011000110101100001010000 
11001031213121001201312131200111120312313120000101201021 
1110111100001131210312131203121312031213131120000112312010 
1101210312111131230312010103131200131313111200120131313100 
10121011110312000001010100000111010131110 
01110111110012011011100000011201000110 
1110010121013120310101212031320000100010000010 


decoded traffic ch bits: 
0001 1) 


100100111111001000010111 


0000010111011100001100100111012001111 


decoded traffic ch bits: 


0101001111123031421311132303120113120111200000000 
0101011000100101010000110110111131201021 


00110012111031011010313113131110001113200000110 
101110011000011001010000001010001010 
0001001010000110111110100101310010000 


0101011000011100110001101100100011021 


1100 1) 


111110111111001010101111 


decoded traffic ch bits: 


0111001100010110101101201131200113123a00021 


11010120001201101012110010100110101120021 
1110001000011110131211131200000111200011021 
10110100110011100000001101201000000121 
10101100001001001101200010121110000110 
0100111111001001000011212001120000011121 
0001100000000010000001001101200000110 


0100 0j 
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decoding process complete 
sending data to syndrome detector to check for frame errors 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Entering Syndrome detector 
data received from traffic channel decoder, length: 1120 
checking for frame error: 
checking for frame error: 
checking for frame error: 
checking for frame error: 





PRR PR 
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